[just talk] what if implicitly typed literals were disallowed

[Adam D. Ruppe]

On Wednesday, 24 October 2012 at 19:04:59 UTC, H. S. Teoh wrote:
> literals should NOT be assigned a type beforehand; the
> compiler should always look for the best fit in the given 
> context first, and THEN if nothing else says anything more
> about the type, fall back to the default type.

Yup. I actually thought D was already doing some of this tbh. 
Heck maybe it is.

I was just focusing on complete customization there. But another 
thing I'd like is for literals to be infinitely sized until 
context forces it down.

So if you were to write some enormous literal like 2^70 that 
should work, then range checks say "hey too big" if you try to 
assign it to a long or otherwise work on it.

But if we had the illusion of infinite size at compile time we 
could do magic like bigint literals by breaking up a huge number 
in CTFE (which should prolly have well defined endianness so your 
ctfe bitops can make sense).

> Anyway, on a related topic: another thing that irks me about D 
> literals is that there is sometimes unexpected implicit copying.

Aye. Don has talked about this before. I disagree that [] should 
be disallowed on non-static data (something IIRC he wants to make 
it a clear literal, removing the need for any runtime stuff at 
all), but if it is static, it certainly should act that way too.

I guess one benefit of [] being defined to be compile time is it 
could be an implicit CTFE force:

auto a = [foo(), 10]; // eval foo as if this was an enum, failing 
to compile if it can't do it


But I really like the convenient syntax of [] on runtime 
variables. We could say array() instead or whatever but meh, it'd 
still be annoying when the code breaks.