On Tuesday, 20 August 2013 at 19:38:34 UTC, 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.
>
> - Jonathan M Davis

What I was trying to say was: is there a good reason they are always dynamic arrays?

What would break if they were made static by default but dynamic on direct assignment to a dynamic array?

On Tuesday, 20 August 2013 at 21:01:43 UTC, Jonathan M Davis wrote:
> On Tuesday, August 20, 2013 22:10:28 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.
>
> It only works with string literal because they're immutable, and the compiler
> optimizes for that by only creating them once (it even puts them in the read-
> only portion of the binary in Linux). The same doesn't hold true for stuff like
> AAs.
>
> - Jonathan M Davis

That wasn't the question, I didn't ask why D does what it does by why it can't do what it doesn't do.

On Wednesday, August 21, 2013 00:23:09 John Colvin wrote:
> What I was trying to say was: is there a good reason they are always dynamic arrays?
> 
> What would break if they were made static by default but dynamic on direct assignment to a dynamic array?

Static arrays are unsafe in many situations, especially if you end up slicing them by accident. The semantics of static arrays are also very different, since they're value types. Static by default would be a very bad idea IMHO. Obviously, static arrays can be desirable, but the programmer needs to be careful any time that they're used. Having the compiler avoid allocating a dynamic array in any situation where a static one is clearly warranted is certainly desirable, as it avoids unnecessary allocations, but that's very different from making static the default.

- Jonathan M Davis

On Tuesday, 20 August 2013 at 22:48:26 UTC, Jonathan M Davis wrote:
> Static arrays are unsafe in many situations, especially if you end up slicing
> them by accident.

But we don't prohibit slicing static arrays. Does not seem consistent approach. If pointer safety would have been really important, `scope` definition and implementation would have been a priority.

> The semantics of static arrays are also very different, since
> they're value types.

But slices of static arrays are still slices. What does it change in practice?

> Static by default would be a very bad idea IMHO.
> Obviously, static arrays can be desirable, but the programmer needs to be
> careful any time that they're used.

How do you expect to convince someone to use D instead of C in its domain if there no such thing as static array literal? It, khem, "literally" does not exist.

What bothers me most here is that we have clear @safe and @system distinction in the language where former is expected to provide correctness guarantees and latter - C-like power. But in practice it is @safe and @no-really-safe-but-we-still-care distinction, with @safe-flavored reasoning severely harming power of common (or even @system) constructs. I have abandoned any hope to change this but it keeps frustrating.

On Wednesday, August 21, 2013 01:21:22 Dicebot wrote:
> On Tuesday, 20 August 2013 at 22:48:26 UTC, Jonathan M Davis
> 
> wrote:
> > Static arrays are unsafe in many situations, especially if you
> > end up slicing
> > them by accident.
> 
> But we don't prohibit slicing static arrays. Does not seem consistent approach. If pointer safety would have been really important, `scope` definition and implementation would have been a priority.
> 
> > The semantics of static arrays are also very different, since they're value types.
> 
> But slices of static arrays are still slices. What does it change in practice?

Slicing a static array is the equivalent of taking the address of a local variable. It's a bug that it's not considered @system.

http://d.puremagic.com/issues/show_bug.cgi?id=8838

And IMHO, the fact that the language _ever_ implicitly slices static arrays is a major design flaw. It's the same as if passing a variable of type T to a function that accept T* implicitly took the address of that variable rather than giving an error, and I think that most people would agree that that's a dumb idea. Unfortunately though, I don't expect it to be fixed at this point, since it would break too much code to do so.

- Jonathan M Davis

On Tuesday, 20 August 2013 at 23:42:48 UTC, Jonathan M Davis wrote:
> And IMHO, the fact that the language _ever_ implicitly slices static arrays is
> a major design flaw.

Here you have my agreement, I tend to dislike any implicit slicing as well as any other implicit operation that is not 100% obvious.

> Slicing a static array is the equivalent of taking the address of a local
> variable. It's a bug that it's not considered @system.

Sure. But array literals won't get static in @system code. That is exactly what I am speaking about - pursuing correctness of @safe severely harms @system. It never was advertised that way. Was it meant to?

On Wednesday, August 21, 2013 02:13:02 Dicebot wrote:
> Sure. But array literals won't get static in @system code. That is exactly what I am speaking about - pursuing correctness of @safe severely harms @system. It never was advertised that way. Was it meant to?

Array literals wouldn't become static in @safe code either. There only case I'm aware of where an array literal effectively becomes static is when directly initializing a static array. And even if there are more cases, none of them would have anything to do with safety. The only time that the compiler would do it would be if it was able to determine that avoiding the allocation wolud be semantically identical (aside from the lack of allocation).

- Jonathan M Davis