On Sunday, January 06, 2013 21:59:32 Andrej Mitrovic wrote:
> On 1/6/13, Jonathan M Davis wrote:
> > If you or someone else
>
> It's going to have to be someone else. When someone asks something on
> IRC/NG and another person responds with "it's because it's not a type
> constructor", or "it's no
On 1/6/13, Jonathan M Davis wrote:
> If you or someone else
It's going to have to be someone else. When someone asks something on
IRC/NG and another person responds with "it's because it's not a type
constructor", or "it's not a storage class" I get completely thrown
off and don't understand what
On Sunday, January 06, 2013 05:33:04 Andrej Mitrovic wrote:
> On 1/6/13, Jonathan M Davis wrote:
> > In D, the term storage class is used for pretty much any attribute on a
> > variable which is not a type constructor
>
> This topic pops up in the newsgroups every once in a while[1]. Maybe
> we s
On 1/6/13, Jonathan M Davis wrote:
> In D, the term storage class is used for pretty much any attribute on a
> variable which is not a type constructor
This topic pops up in the newsgroups every once in a while[1]. Maybe
we should properly document it in the docs, a special section on
storage cla
On Saturday, January 05, 2013 17:15:51 Ali Çehreli wrote:
> On 01/05/2013 04:59 PM, Jonathan M Davis wrote:
> > D's auto _is_ automatic type deduction like in C++11.
>
> It must have changed in the last couple of years. I see that the
> documentation is now different:
>
>http://dlang.org/att
On 01/05/2013 04:59 PM, Jonathan M Davis wrote:
> D's auto _is_ automatic type deduction like in C++11.
It must have changed in the last couple of years. I see that the
documentation is now different:
http://dlang.org/attribute.html#auto
It now says "The auto attribute is used when there a
On Saturday, January 05, 2013 16:18:51 Ali Çehreli wrote:
> On 01/05/2013 12:09 PM, Simen Kjaeraas wrote:
> > A little details is that immutable auto is unnecessary, as immutable
> > implies auto (the details are more complex, but that's the short
>
> version).
>
> It is true that the OP does n
On 01/05/2013 12:09 PM, Simen Kjaeraas wrote:
> A little details is that immutable auto is unnecessary, as immutable
> implies auto (the details are more complex, but that's the short
version).
It is true that the OP does not need auto when there is already
immutable but does immutable really
On Saturday, 5 January 2013 at 20:09:24 UTC, Simen Kjaeraas wrote:
The reason is that ranges may not be immutable or const.
Ranges need to be mutated (popFront) to be iterable, and your
filtered
range cannot be mutated, by virtue of being immutable. I'm
surprised that
seq and filtered work, b
On 2013-52-05 20:01, Michael Engelhardt wrote:
Hi,
just playing around with the functional capabilities of D. One concept
of the pure functional programming is that variables should not be
reassigned, so the best(?) way to assure this is using immutable:
immutable auto gen = sequence
Hi,
just playing around with the functional capabilities of D. One
concept of the pure functional programming is that variables
should not be reassigned, so the best(?) way to assure this is
using immutable:
immutable auto gen = sequence!("n");
immutable auto seq = take(gen,10);
i
11 matches
Mail list logo
