On 06/11/12 07:09, Rob T wrote:
On Friday, 2 November 2012 at 22:33:37 UTC, Rob T wrote:
I discovered it fails to compile when inside a function with "auto" as
the return type.
auto test()
{
throw new Exception( mixin(__FUNCTION) );
return 0;
}
Error: forward reference to test
but this
On 2012-11-05 23:10, Andrei Alexandrescu wrote:
I updated
http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0
as follows:
=
Late-Breaking News: Smile, You're On Camera!
It's confirmed - through volunteer support, the conference talks will be
recor
On Tuesday, November 06, 2012 08:49:26 Andrei Alexandrescu wrote:
> On 11/6/12 4:36 AM, H. S. Teoh wrote:
> > Hmm. Another idea just occurred to me. The basic problem here is that we
> > are conflating two kinds of values, transient and persistent, under a
> > single name .front. What if we explici
On 11/6/12 7:48 AM, H. S. Teoh wrote:
On Tue, Nov 06, 2012 at 05:49:44AM +0100, Tommi wrote:
On Tuesday, 6 November 2012 at 04:31:56 UTC, H. S. Teoh wrote:
The problem is that you can't do this in generic code, because
generic code by definition doesn't know how to copy an arbitrary
type.
I'm
On 11/6/12 8:40 AM, Andrei Alexandrescu wrote:
On 11/6/12 4:15 AM, Jesse Phillips wrote:
On Monday, 5 November 2012 at 21:57:01 UTC, Ali Çehreli wrote:
On 10/31/2012 05:35 PM, Faux Amis wrote:
> I will pledge 100$ if that would mean videos.
There is a change on the project page: :)
"Late-Bre
On 11/6/12 6:49 AM, Tommi wrote:
On Tuesday, 6 November 2012 at 04:31:56 UTC, H. S. Teoh wrote:
The problem is that you can't do this in generic code, because generic
code by definition doesn't know how to copy an
arbitrary type.
I'm not familiar with that definition of generic code. But I do
On 11/6/12 4:36 AM, H. S. Teoh wrote:
Hmm. Another idea just occurred to me. The basic problem here is that we
are conflating two kinds of values, transient and persistent, under a
single name .front. What if we explicitly name them? Say, .copyFront for
the non-transient value and .refFront for t
On Monday, 5 November 2012 at 08:37:49 UTC, Faux Amis wrote:
Ok, good to see that you are replying to incorrectly scoped
variables, but this is not the point I am trying to make. I
know you should always keep the scope as small as possible.
Eh? I'm confused. The second half of my post certainl
On Tuesday, 6 November 2012 at 04:49:45 UTC, Tommi wrote:
On Tuesday, 6 November 2012 at 04:31:56 UTC, H. S. Teoh wrote:
The problem is that you can't do this in generic code, because
generic code by definition doesn't know how to copy an
arbitrary type.
I'm not familiar with that definition
On 11/6/12 4:15 AM, Jesse Phillips wrote:
On Monday, 5 November 2012 at 21:57:01 UTC, Ali Çehreli wrote:
On 10/31/2012 05:35 PM, Faux Amis wrote:
> I will pledge 100$ if that would mean videos.
There is a change on the project page: :)
"Late-Breaking News: Smile, You're On Camera!
It's confi
On Friday, 2 November 2012 at 22:33:37 UTC, Rob T wrote:
I discovered it fails to compile when inside a function with
"auto" as the return type.
auto test()
{
throw new Exception( mixin(__FUNCTION) );
return 0;
}
Error: forward reference to test
but this works
int test()
{
throw ne
On Tue, Nov 06, 2012 at 05:49:44AM +0100, Tommi wrote:
> On Tuesday, 6 November 2012 at 04:31:56 UTC, H. S. Teoh wrote:
> >The problem is that you can't do this in generic code, because
> >generic code by definition doesn't know how to copy an arbitrary
> >type.
>
> I'm not familiar with that defi
On Tuesday, 6 November 2012 at 04:31:56 UTC, H. S. Teoh wrote:
The problem is that you can't do this in generic code, because
generic code by definition doesn't know how to copy an
arbitrary type.
I'm not familiar with that definition of generic code. But I do
feel that there's a pretty big p
On Tue, Nov 06, 2012 at 03:36:54AM +0200, Andrei Alexandrescu wrote:
> On 11/6/12 3:06 AM, H. S. Teoh wrote:
> >I've already given a number of non-trivial examples of transient
> >forward ranges, and apparently deadalnix has also encountered the
> >same issue.
>
> I'd like to build more of this ar
On Tuesday, 6 November 2012 at 01:11:08 UTC, Malte Skarupke wrote:
I want something similar to the stl vector, which only
re-allocates once your array grows past a certain size, not on
every append.
std.container.Array is similar to a shared_ptr>.
On Tue, Nov 06, 2012 at 04:12:17AM +0100, Jonathan M Davis wrote:
> On Monday, November 05, 2012 18:36:53 H. S. Teoh wrote:
> > Hmm. Another idea just occurred to me. The basic problem here is
> > that we are conflating two kinds of values, transient and
> > persistent, under a single name .front.
On Tue, Nov 06, 2012 at 05:18:18AM +0100, Tommi wrote:
> I don't think this whole issue has anything to do with ranges. I
> think this is an issue of assuming that the symbol = means "copy
> what's on the right to what's on the left". When in reality, = could
> mean: (if what's on the right has ref
On 11/05/2012 05:36 AM, Robert wrote:
I just developed a proof-of-concept implementation of an improved
std.signals.
Cool.
1. Passing a delegate to connect, which basically is an extended (void*)
and assuming it is an object delegate, does not feel quite right in D,
where we usually try to
I don't think this whole issue has anything to do with ranges. I
think this is an issue of assuming that the symbol = means "copy
what's on the right to what's on the left". When in reality, =
could mean: (if what's on the right has reference semantics)
"make what's on the left reference the sa
On Tuesday, November 06, 2012 03:28:09 Malte Skarupke wrote:
> Thanks, that explains it well. I must admit that I didn't fully
> understand slices before. I've read the linked article and am
> baffled that this is seen as acceptable behavior. I will most
> certainly never use dynamic arrays or slic
On Monday, November 05, 2012 18:36:53 H. S. Teoh wrote:
> Hmm. Another idea just occurred to me. The basic problem here is that we
> are conflating two kinds of values, transient and persistent, under a
> single name .front. What if we explicitly name them? Say, .copyFront for
> the non-transient v
On Tue, Nov 06, 2012 at 02:03:45AM +0100, Jonathan M Davis wrote:
[...]
> The only solutions that I see at this point are
>
> 1. Exclude transience completely.
>
> 2. Mark ranges as transient in some way and force algorithms to take
> this new trait into account.
>
> 3. Insist that input ranges
On Tuesday, 6 November 2012 at 01:25:39 UTC, Jonathan M Davis
wrote:
On Tuesday, November 06, 2012 02:11:06 Malte Skarupke wrote:
Following code:
void main()
{
import core.memory;
GC.disable();
scope(exit) GC.enable();
int[] a = [1, 2, 3, 4, 5];
foreach(i; 0 .. 10)
{
--a.length;
a ~= i
Jonathan M Davis:
assumeSafeAppend needs to be called every time that length is
decremented.
Right. (But adding one such call inside a critical loop...).
Bye,
bearophile
On Monday, 5 November 2012 at 21:57:01 UTC, Ali Çehreli wrote:
On 10/31/2012 05:35 PM, Faux Amis wrote:
> I will pledge 100$ if that would mean videos.
There is a change on the project page: :)
"Late-Breaking News: Smile, You're On Camera!
It's confirmed - through volunteer support, the confe
Le 06/11/2012 02:40, Andrei Alexandrescu a écrit :
On 11/6/12 2:44 AM, deadalnix wrote:
To be honest, my biggest fear isn't that this proposal is rejected, but
that we fallback as default on the input range = transient / forward
range = non transient scheme, because we fail to come up with somet
Le 06/11/2012 02:36, Andrei Alexandrescu a écrit :
On 11/6/12 3:06 AM, H. S. Teoh wrote:
I've already given a number of
non-trivial examples of transient forward ranges, and apparently
deadalnix has also encountered the same issue.
I'd like to build more of this argument. I pointed out that yo
On Monday, 22 October 2012 at 17:25:28 UTC, Andrei Alexandrescu
wrote:
We're on! For one month starting today, we're raising funding
for DConf 2013.
http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0
Please pledge your support and encourage your friends
On 11/6/12 2:44 AM, deadalnix wrote:
To be honest, my biggest fear isn't that this proposal is rejected, but
that we fallback as default on the input range = transient / forward
range = non transient scheme, because we fail to come up with something
better, or that the status quo is choosen (as b
On 11/6/12 3:06 AM, H. S. Teoh wrote:
I've already given a number of
non-trivial examples of transient forward ranges, and apparently
deadalnix has also encountered the same issue.
I'd like to build more of this argument. I pointed out that your range
is actually defining .dup, not .save. I th
On Tuesday, November 06, 2012 02:27:24 bearophile wrote:
> void main() {
> auto array = [1, 2, 3, 4, 5];
> array.assumeSafeAppend();
> foreach (i; 0 .. 10_000_000) {
> array.length--;
> array ~= i;
> }
> }
assumeSafeAppend needs to be called every time that length is decremented. It
does nothing
Malte Skarupke:
void main()
{
import core.memory;
GC.disable();
scope(exit) GC.enable();
int[] a = [1, 2, 3, 4, 5];
foreach(i; 0 .. 10)
{
--a.length;
a ~= i;
}
}
That loop will keep on allocating in every iteration until your
memory is full.
On Tuesday, November 06, 2012 02:11:06 Malte Skarupke wrote:
> Following code:
>
> void main()
> {
> import core.memory;
> GC.disable();
> scope(exit) GC.enable();
>
> int[] a = [1, 2, 3, 4, 5];
> foreach(i; 0 .. 10)
> {
> --a.length;
> a ~= i;
> }
> }
>
> That loop will keep on allocati
On 11/05/2012 05:11 PM, Malte Skarupke wrote:
Following code:
void main()
{
import core.memory;
GC.disable();
scope(exit) GC.enable();
int[] a = [1, 2, 3, 4, 5];
foreach(i; 0 .. 10)
{
--a.length;
a ~= i;
}
}
That loop will keep on allocating in every iteration until your memory
is full
Following code:
void main()
{
import core.memory;
GC.disable();
scope(exit) GC.enable();
int[] a = [1, 2, 3, 4, 5];
foreach(i; 0 .. 10)
{
--a.length;
a ~= i;
}
}
That loop will keep on allocating in every iteration until your
memory is full.
Let's say I want to
On Tue, Nov 06, 2012 at 01:44:28AM +0100, deadalnix wrote:
> Le 06/11/2012 01:21, Andrei Alexandrescu a écrit :
[...]
> >Good solutions are found in the minds of people. Starting from the
> >idea that .transient is unacceptably complicated, work from that
> >angle. You can't claim you have reached
On Monday, November 05, 2012 16:49:42 H. S. Teoh wrote:
> On Mon, Nov 05, 2012 at 11:51:35PM +0200, Andrei Alexandrescu wrote:
> [...]
>
> > >With Andrei's proposal, all code that assumes transient .front with
> > >input ranges are broken by definition.
> >
> > I think this should be: all code th
On Mon, Nov 05, 2012 at 11:51:35PM +0200, Andrei Alexandrescu wrote:
[...]
> >With Andrei's proposal, all code that assumes transient .front with
> >input ranges are broken by definition.
>
> I think this should be: all code that DOES NOT assume transient
> .front with input ranges is broken.
The
Le 06/11/2012 01:21, Andrei Alexandrescu a écrit :
I'd like to see a proposal discarded in favor of a better proposal. I'm
certain I can say that we don't have one.
Good solutions are found in the minds of people. Starting from the idea
that .transient is unacceptably complicated, work from tha
On 11/6/12 1:26 AM, deadalnix wrote:
Le 05/11/2012 22:51, Andrei Alexandrescu a écrit :
On 11/5/12 9:45 PM, H. S. Teoh wrote:
Besides, almost *all* of those wrapper ranges are currently _broken_ for
transient ranges. You get undefined behaviour when you inadvertently
pass a transient range to t
Am Mon, 05 Nov 2012 13:10:35 +0100
schrieb "Paulo Pinto" :
> On Monday, 5 November 2012 at 11:06:39 UTC, monarch_dodra wrote:
> > On Monday, 5 November 2012 at 10:22:02 UTC, Nick Sabalausky
> > wrote:
> >> On Mon, 05 Nov 2012 11:00:27 +0100
> >> "jdrewsen" wrote:
> >>
> >>> It seems like the C++
Le 05/11/2012 22:51, Andrei Alexandrescu a écrit :
On 11/5/12 9:45 PM, H. S. Teoh wrote:
Besides, almost *all* of those wrapper ranges are currently _broken_ for
transient ranges. You get undefined behaviour when you inadvertently
pass a transient range to them.
It's not undefined behavior, it
On 11/5/2012 2:33 PM, Iain Buclaw wrote:> Could also bring a recording device,
incase the recorded audio on the
> video is poor :o)
I can recommend a backup recording. I had a talk of mine once that got video,
but no audio, because the mike was accidentally left off. It was a smallish
venue, s
On 5 November 2012 22:18, Ali Çehreli wrote:
> On 11/05/2012 02:10 PM, Andrei Alexandrescu wrote:
>>
>> I updated
>>
>> http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0
>> as follows:
>>
>> =
>> Late-Breaking News: Smile, You're On Camera!
>>
>> I
On 11/05/2012 02:10 PM, Andrei Alexandrescu wrote:
I updated
http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0
as follows:
=
Late-Breaking News: Smile, You're On Camera!
It's confirmed - through volunteer support, the conference talks will be
re
I updated
http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0
as follows:
=
Late-Breaking News: Smile, You're On Camera!
It's confirmed - through volunteer support, the conference talks will be
recorded and posted on the Net for free! We're prep
On Sunday, 4 November 2012 at 22:31:56 UTC, evansl wrote:
Yet, the wiki page:
http://en.wikipedia.org/wiki/Tagged_union
says:
a tag field explicitly indicates which one is in use.
and I don't see any indication of a tag field in the
std_variant.html
I remember a while back asking about t
On 11/5/12 9:45 PM, H. S. Teoh wrote:
Besides, almost *all* of those wrapper ranges are currently _broken_ for
transient ranges. You get undefined behaviour when you inadvertently
pass a transient range to them.
It's not undefined behavior, it's just surprising behavior. UB would be
a fair amo
On 11/05/12 13:53, Robert Jacques wrote:
> On Monday, 5 November 2012 at 14:13:41 UTC, evansl wrote:
>> On 11/05/12 00:33, Robert Jacques wrote:
>>> On Sunday, 4 November 2012 at 22:33:46 UTC, Alex Rønne Petersen
>>> wrote:
On 05-11-2012 00:31, evansl wrote:
>
> [snip]
>
>> If std.Algebraic
Hi Mr. Sigaud,
I seem to have run into some issues with "Semantic Actions"... I
can't get it working, neither from following the
tutorial-description nor from attempting to compile the official
xml example.
rdmd.exe --main pegged\examples\xml.d
pegged\examples\xml.d(59): Error: found ')' ins
On Monday, 5 November 2012 at 14:13:41 UTC, evansl wrote:
On 11/05/12 00:33, Robert Jacques wrote:
On Sunday, 4 November 2012 at 22:33:46 UTC, Alex Rønne
Petersen
wrote:
On 05-11-2012 00:31, evansl wrote:
[snip]
If std.Algebraic is like Boost.Variant, then duplicate
bounded types are not a
On Mon, Nov 05, 2012 at 01:42:47PM -0500, Jonathan M Davis wrote:
> On Monday, November 05, 2012 15:48:41 deadalnix wrote:
> > HS Teoh explained it nicely.
> >
> > The responsibility of using .transient or not belong to the consumer.
> > Only the consumer can know if a transient range is suitable.
On Monday, 5 November 2012 at 19:07:13 UTC, Robert wrote:
Hi!Could you write some examples for struct and non-object
delegates?
Sure!
Something like:
struct Observer {
void observe(int a, int b) {
// ...
}
}
void main() {
Signal!(int, int) s1;
Le 05/11/2012 19:42, Jonathan M Davis a écrit :
On Monday, November 05, 2012 15:48:41 deadalnix wrote:
HS Teoh explained it nicely.
The responsibility of using .transient or not belong to the consumer.
Only the consumer can know if a transient range is suitable.
So you don't wrap a transient r
On Monday, November 05, 2012 15:48:41 deadalnix wrote:
> HS Teoh explained it nicely.
>
> The responsibility of using .transient or not belong to the consumer.
> Only the consumer can know if a transient range is suitable.
>
> So you don't wrap a transient range. You wrap a non transient range,
>
> Hi!Could you write some examples for struct and non-object
> delegates?
>
Sure!
Something like:
struct Observer {
void observe(int a, int b) {
// ...
}
}
void main() {
Signal!(int, int) s1;
Signal!int s2
Observer o;
s1.connect
On Monday, 5 November 2012 at 13:35:26 UTC, Robert wrote:
Hi there!
I just developed a proof-of-concept implementation of an
improved
std.signals.
Things I did not like about the current implementation:
1. Passing a delegate to connect, which basically is an
extended (void*)
and assuming it
Thought so. Thank you!
> Presumably, it's left over from
> some previous refactoring.
>
> - Jonathan M Davis
On Monday, November 05, 2012 14:36:55 Robert wrote:
> Another thing I'd like to ask Walter, is what the "L1:" label is for in
> connect(), is it just some left over or has it some special internal
> compiler thing meaning?
It's a label. There's nothing special about it. You jump to them with gotos
On Monday, November 05, 2012 11:00:27 jdrewsen wrote:
> It seems like the C++ committee is speeding up development adding
> lots of the goodies from D like Ranges, static if, template
> contraints etc.
>
> Will D still have a case when C++ gets this done?
>
> I wonder if Andrei is part of the C++
On Mon, Nov 05, 2012 at 01:19:04PM +0100, jdrewsen wrote:
> On Monday, 5 November 2012 at 11:39:54 UTC, Erèbe wrote:
> >On Monday, 5 November 2012 at 10:00:29 UTC, jdrewsen wrote:
> >>It seems like the C++ committee is speeding up development
> >>adding lots of the goodies from D like Ranges, stati
On 11/05/2012 11:22 AM, Nick Sabalausky wrote:
On Mon, 05 Nov 2012 11:00:27 +0100
"jdrewsen" wrote:
It seems like the C++ committee is speeding up development adding
lots of the goodies from D like Ranges, static if, template
contraints etc.
Will D still have a case when C++ gets this done?
Yeah, I know. Currently bug fixes are way more important then new features
and this one really really looks like a dirty hack. But the problem it
solves is very real. I honestly don't know what to do about it.
On Mon, Nov 5, 2012 at 6:38 PM, deadalnix wrote:
> Le 27/10/2012 07:39, Gor Gyolchany
I don't see anything related to this issue.
On Sun, Oct 28, 2012 at 5:41 AM, Chris Nicholson-Sauls <
ibisbase...@gmail.com> wrote:
> On Saturday, 27 October 2012 at 05:39:59 UTC, Gor Gyolchanyan wrote:
>
>> I've stumbled upon this numerous times and I wish I could automate this
>> somehow.
>> Th
Le 04/11/2012 18:35, Tommi a écrit :
I have a fundamental language design talking point for you. It's not
specific to D. I claim that, most of the time, a programmer cannot, and
shouldn't have to, make the decision of whether to allocate on stack or
heap. For example:
void func(T)()
{
auto t =
Le 05/11/2012 11:22, Nick Sabalausky a écrit :
On Mon, 05 Nov 2012 11:00:27 +0100
"jdrewsen" wrote:
It seems like the C++ committee is speeding up development adding
lots of the goodies from D like Ranges, static if, template
contraints etc.
Will D still have a case when C++ gets this done?
Le 05/11/2012 08:58, Jonathan M Davis a écrit :
On Sunday, November 04, 2012 21:07:46 H. S. Teoh wrote:
Stop right there. You're contradicting yourself. You kept saying that
transient ranges are rare, abnormal, etc., and now you say they are a
potentially large number of range types? I'm sorry,
Le 05/11/2012 05:42, Jonathan M Davis a écrit :
On Sunday, November 04, 2012 20:20:58 H. S. Teoh wrote:
What's not to like about this proposal?
It creates massive code duplication all over the place, and it's yet one more
range concept that everyone has to remember and keep in mind. Remember t
Le 05/11/2012 04:47, Jonathan M Davis a écrit :
On Sunday, November 04, 2012 19:41:39 H. S. Teoh wrote:
On Sun, Nov 04, 2012 at 07:11:22PM -0800, Jonathan M Davis wrote:
On Sunday, November 04, 2012 15:40:18 deadalnix wrote:
Le 04/11/2012 03:26, Jonathan M Davis a écrit :
3. Make it so that r
On Sun, Nov 04, 2012 at 11:58:18PM -0800, Jonathan M Davis wrote:
> On Sunday, November 04, 2012 21:07:46 H. S. Teoh wrote:
> > Stop right there. You're contradicting yourself. You kept saying
> > that transient ranges are rare, abnormal, etc., and now you say they
> > are a potentially large numbe
Le 05/11/2012 04:21, Jonathan M Davis a écrit :
However, that means that we need to be very clear about the fact that input
ranges can have transient fronts and that algorithms cannot assume that their
fronts are not transient (something that only you appear to have thought was
clear).
Note tha
Le 04/11/2012 23:10, H. S. Teoh a écrit :
On Sun, Nov 04, 2012 at 12:38:06PM -0500, Andrei Alexandrescu wrote:
On 11/4/12 12:26 PM, deadalnix wrote:
I think it fit nicely D's phylosophy, in the sense it does provide a
safe, easy to use interface while providing a backdoor when this
isn't enough
Era Scarecrow:
It's not worth the unsafety of the whole switch.
What? I'd need a little explanation what you'd mean.
I meant that semantically clean language features help avoid
troubles later while you program :-)
besides, 'switch with' and 'with switch' are practically
identical... ar
Le 05/11/2012 04:11, Jonathan M Davis a écrit :
On Sunday, November 04, 2012 15:40:18 deadalnix wrote:
Le 04/11/2012 03:26, Jonathan M Davis a écrit :
3. Make it so that ranges which can be transient are non-transient by
default but provide a function to get at a transient version for speed
(wh
Le 31/10/2012 21:33, Chris Nicholson-Sauls a écrit :
Some related actual code from a while back:
##
ParseTree prune ( ParseTree p ) {
p.children = p.children.dup;
foreach ( ref child ; p.children ) {
child = prune( child );
}
switch ( p.ruleName )
Le 27/10/2012 07:39, Gor Gyolchanyan a écrit :
I've stumbled upon this numerous times and I wish I could automate this
somehow.
The idea is to have some mixin templates mixed into classes
automatically when they inherit from some base class.
For instance, advanced RTTI methods, which analyze the
On 11/05/12 00:33, Robert Jacques wrote:
> On Sunday, 4 November 2012 at 22:33:46 UTC, Alex Rønne Petersen
> wrote:
>> On 05-11-2012 00:31, evansl wrote:
>>> http://dlang.org/phobos/std_variant.html
>>>
>>> says:
>>>
>>> This module implements a discriminated union type (a.k.a. tagged union,
>>>
Hi there!
I just developed a proof-of-concept implementation of an improved
std.signals.
Things I did not like about the current implementation:
1. Passing a delegate to connect, which basically is an extended (void*)
and assuming it is an object delegate, does not feel quite right in D,
where
On Monday, 5 November 2012 at 08:01:57 UTC, Jonathan M Davis
wrote:
auto ref's current semantics can't possibly work with
non-templated functions,
and it's clear that there are good reasons for keeping auto ref
as it is now
for templates. So, either we make it work with non-templated
functions
On Monday, 5 November 2012 at 10:00:29 UTC, jdrewsen wrote:
Will D still have a case when C++ gets this done?
C++ does a pretty good job on a lot of things, but there's a
bunch of little things that just make it a little more
frustrating day to day than D.
There's still a bunch of big diffe
On Monday, 5 November 2012 at 11:06:39 UTC, monarch_dodra wrote:
On Monday, 5 November 2012 at 10:22:02 UTC, Nick Sabalausky
wrote:
On Mon, 05 Nov 2012 11:00:27 +0100
"jdrewsen" wrote:
It seems like the C++ committee is speeding up development
adding lots of the goodies from D like Ranges, st
On Monday, 5 November 2012 at 10:22:02 UTC, Nick Sabalausky wrote:
On Mon, 05 Nov 2012 11:00:27 +0100
"jdrewsen" wrote:
It seems like the C++ committee is speeding up development
adding lots of the goodies from D like Ranges, static if,
template contraints etc.
Will D still have a case when
On 04/11/12 15:30, stonemaster wrote:
On Thursday, 1 November 2012 at 15:56:24 UTC, Tobias Pankrath wrote:
On Thursday, 1 November 2012 at 15:20:11 UTC, Andrei Alexandrescu wrote:
On 11/1/12 9:47 AM, Paulo Pinto wrote:
Hi everyone,
I just saw this online.
The German magazine c't kompakt has
On Mon, 05 Nov 2012 11:00:27 +0100
"jdrewsen" wrote:
> It seems like the C++ committee is speeding up development adding
> lots of the goodies from D like Ranges, static if, template
> contraints etc.
>
> Will D still have a case when C++ gets this done?
>
Yes, even if they go and add all o
It seems like the C++ committee is speeding up development adding
lots of the goodies from D like Ranges, static if, template
contraints etc.
Will D still have a case when C++ gets this done?
I wonder if Andrei is part of the C++ Ranges Study Group?
The Future of C++:
http://channel9.msdn.com
On Monday, 5 November 2012 at 08:53:48 UTC, Johannes Pfau wrote:
Am Sun, 04 Nov 2012 16:48:26 +0100
schrieb "monarch_dodra" :
I'm wondering if there is a way to know you are in deprecated
mode or not?
The deprecated attribute is great, because it gives a clear
compile error (as opposed to a
Am Mon, 05 Nov 2012 07:33:47 +0100
schrieb "Robert Jacques" :
> On Sunday, 4 November 2012 at 22:33:46 UTC, Alex Rønne Petersen
> wrote:
> > On 05-11-2012 00:31, evansl wrote:
> >> http://dlang.org/phobos/std_variant.html
> >>
> >> says:
> >>
> >> This module implements a discriminated union ty
Am Sun, 04 Nov 2012 16:48:26 +0100
schrieb "monarch_dodra" :
> I'm wondering if there is a way to know you are in deprecated
> mode or not?
>
> The deprecated attribute is great, because it gives a clear
> compile error (as opposed to a static if, which just hides the
> function completely).
>
On 05/11/2012 01:45, Chris Cain wrote:
On Sunday, 4 November 2012 at 23:51:15 UTC, Faux Amis wrote:
In your last paragraph you are getting to my point in my other post:
I think there is nothing wrong with a module scope private var as in D
a module is the first encapsulation and adding a wrapper
On Monday, November 05, 2012 06:05:07 Rob T wrote:
> On Monday, 5 November 2012 at 03:26:10 UTC, Jonathan M Davis
>
> wrote:
> > And when we argued for altering it so that it operated like
> > const ref in C++
> > (which allows const ref in D to continue to function like it
> > does now), some
> >
91 matches
Mail list logo
