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