Is enum static?

Jonathan M Davis jmdavisProg at gmx.com
Tue Aug 20 14:01:36 PDT 2013


On Tuesday, August 20, 2013 13:35:43 H. S. Teoh wrote:
> On Tue, Aug 20, 2013 at 03:38:18PM -0400, Jonathan M Davis wrote:
> > On Tuesday, August 20, 2013 21:33:23 John Colvin wrote:
> > > I presume there's a good reason why we don't have:
> > > enum a = [1,2,3,4];
> > > assert assert(is(typeof(a) == int[4]));
> > > 
> > > this works after all:
> > > enum int[4] a = [1,2,3,4];
> > > assert assert(is(typeof(a) == int[4]));
> > 
> > Array literals are always dynamic arrays, so [1, 2, 3, 4] is int[] by
> > definition.
> 
> Wait, is that dynamic *by default*, or is it *always* dynamic? If the
> latter, I think we should fix the language.

It is _always_ dynamic.

> It should be possible to write
> things like:
> 
> byte[] a = [1,2,3,4];
> 
> and *not* incur the overhead of allocating an int[] and then copying it
> over (with implicit casting) to the byte[].

That doesn't allocate anymore, and there are plenty of cases like that 
(several of which I'm sure still allocate), but it's essentially an 
optimization any time that an array literal doesn't end up allocating.

> On that note, I find it Very Evil that this doesn't work properly:
> 
> char[] a = "abc";
> const(char)[] b = "abc";
> 
> Instead, you have to do:
> 
> char[] a = "abc".dup;
> const(char)[] b = "abc".dup;
>
> I can accept that having an explicit .dup or .idup is a good thing when
> the source string is a variable, but in this case, the compiler *should*
> be smart enough to know, hey, "abc" is a literal and is being
> immediately assigned to a char[], so the user must intend that it's used
> only to initialize the char[], so I don't need to actually allocate a
> *string* (as in, immutable(char)[]) for the literal and copy it, but
> instead, I should generate code to initialize each array element.
> 
> tl;dr, I think D literals are assigned a type far too early in the
> compilation process. The intended meaning of a literal shouldn't be
> bound until the compiler is able to infer from context what type is
> actually required.

Honestly, I have no problem with this. The type of string literal is 
immutable(char)[], so having to dup it makes sense. And you don't incur any 
extra allocations, because string literals are part of the generated binary 
rather than being allocated at runtime (and on Linux, they end up in the read-
only portion). So, you're only allocating once (when you dup), which is what 
what happen if the compiler allowed the code that you're looking for.

- Jonathan M Davis


More information about the Digitalmars-d-learn mailing list