Is enum static?

[H. S. Teoh]

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 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[].

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.


On Tue, Aug 20, 2013 at 10:10:28PM +0200, JS wrote:
> On Monday, 19 August 2013 at 18:28:10 UTC, Ali Çehreli wrote:
> >On 08/19/2013 03:18 AM, Borislav Kosharov wrote:> So if I want to
> >have a string constant it is a lot better to declare it as:
> >>
> >> static immutable string MY_STRING = "Some string";
> >>
> >> Because it won't be duplicated?
> >
> >enum is fine with strings.
> >
> >It is a common space optimization of the compilers not to
> >duplicate identical strings. The following program includes just
> >one "hello world" in the compiled object file:
> >
> 
> And why can't this be done with any compile time objects? AA's that
> are identical be collated similar to strings.

The problem is that AA's are mutable at runtime. You wouldn't want
something like this to happen:

	auto aa1 = ["a": 1, "b": 2];
	auto aa2 = ["a": 1, "b": 2];
	aa1.remove("a");
	auto x = aa2["a"];	// oops, you get an error if the two AA
				// literals referred to the same thing

You *could* collapse literals into the same object if they were
immutable, though. I don't know if DMD does that (yet), but if not, it
should! Honestly, the way literals are handled in D is one of the things
I'm not very happy with. There's too many implicit allocations that may
not be immediately obvious.

Also, the fact that static immutable AA literals are currently not
possible is a lamentable state of affairs. :-( The compiler *should* be
able to generate the data for an AA literal at compile-time in such a
way that it can be put into the executable and used directly at runtime
without requiring runtime initialization.


T

-- 
Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel