H. S. Teoh 
| On Tue, Aug 20, 2013 at 05:01:36PM -0400, Jonathan M Davis wrote:
> On Tuesday, August 20, 2013 13:35:43 H. S. Teoh wrote:
[...]
> > 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.
That's what troubles me. Allocations shouldn't be the default; they should be fallback when they can't be avoided.
> > 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.
[...]
It's not just with strings. What about this:
byte[] a = [1,2,3];
uint[] b = [1,2,3];
long[] c = [1,2,3];
? Will the compiler emit an int[] (or immutable(int)[]?) to hold each
literal, and then copy the contents (with casting) to the target arrays
at runtime?
I argue that [1,2,3] has a different meaning in each of these lines. On
the first line, it should mean [byte(1), byte(2), byte(3)], on the
second line it should mean [1u, 2u, 3u], and on the third line it should
mean [1L, 2L, 3L]. The compiler should not assign it to int[] except as
a fallback (e.g., if you wrote auto d = [1,2,3];, then it would default
to int[]).
This issues shows up in places like IFTI, where [1,2,3] is assigned too early to be int[], so it fails to match a template function that expects byte[]. IFTI can of course be hacked to work around this (and maybe already has), but the fundamental problem is that literals are assumed to be of a particular type far too early on. They really should have flexible type, adaptable to the context they appear in. A literal like [1,2,3] should not be be assumed to be int[] until the compiler determines that the context does not provide sufficient information to deduce the intended type. IOW, int[] should be a *fallback* type for [1,2,3], not something presumed up-front.
T
--
Which is worse: ignorance or apathy? Who knows? Who cares? -- Erich Schubert
|
Permalink
Reply
