March 16, 2017
On Thu, Mar 16, 2017 at 02:36:15PM -0700, Jonathan M Davis via Digitalmars-d-learn wrote: [...]
> Honestly, I think that it was a big mistake to have implicit slicing of static arrays in the language at all.

That makes at least 3 of us -- Adam, you, me. I'm sure there are more.


> Unfortunately, last time I tried to convince Walter of that, he seemed to think that the @safety improvements to the compiler were going to fix the problem, and they will help, but I'm of the opinion that slicing of static arrays should always be explicit. It's too easy to miss what's going on otherwise, even if it isn't an @safety problem.

Yeah, it's one of those things that seemed like a good idea on the surface, like autodecoding, but the deeper you go, the more troubles you discover.  Unlike autodecoding, though, any code breakage caused by killing autoslicing of static arrays will, I speculate, only affect already-buggy code that ought to be fixed anyway.  And AFAIK, nobody has argued *for* implicit slicing of static arrays.


> In any case, the @safety fixes that are underway should eventually at least flag this as @system if not result in it being outright illegal. And I think that there's a good case to make any variant of this issue be illegal if it's guaranteed that you're going to end up with a pointer to invalid memory.
[...]

The wrinkle is that the way dmd currently implements this, AFAICT, is to leave returned static array rvalues on the stack until the end of the function, even if it's inside a nested sub-scope that is followed by other nested sub-scopes that may go even deeper. It's not wrong to do this -- there's no requirement per se that stack variables have to be freed immediately upon leaving a nested scope so that the stack space can be reused by subsequent local variables. But it does obscure this particular issue by hiding the problem of an escaping reference to an rvalue that has long gone out of scope.

Not even -dip1000 catches this case right now, which I think is a bug, because the way I understand DIP 1000 is that this should be illegal.


T

-- 
It won't be covered in the book. The source code has to be useful for something, after all. -- Larry Wall
March 16, 2017
On Thu, Mar 16, 2017 at 06:51:45PM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote:
> On Thursday, 16 March 2017 at 18:07:09 UTC, Petar Kirov [ZombineDev] wrote:
> > Why don't you use -dip1000???
> 
> Because it isn't the default. But even if it was, people would ask "why is this giving me an error?" and the same explanation would need to be given.  Certainly, a compile error is better than runtime corruption, but the underlying issue ought to be fixed anyway.

Not to mention that even with -dip1000, the fundamental problem still happens:

	int[16] func();
	int[] x = func();	// allowed even with -dip1000

	x[0] = 123; // this writes to the now out-of-scope rvalue returned by func()


T

-- 
Doubtless it is a good thing to have an open mind, but a truly open mind should be open at both ends, like the food-pipe, with the capacity for excretion as well as absorption. -- Northrop Frye
March 18, 2017
On Thursday, 16 March 2017 at 22:06:24 UTC, H. S. Teoh wrote:
> On Thu, Mar 16, 2017 at 02:36:15PM -0700, Jonathan M Davis via Digitalmars-d-learn wrote: [...]
>> Honestly, I think that it was a big mistake to have implicit slicing of static arrays in the language at all.
>
> That makes at least 3 of us -- Adam, you, me. I'm sure there are more.

Make it 4.
March 20, 2017
On Thursday, 16 March 2017 at 16:13:33 UTC, Carl Sturtivant wrote:
> What's going on here?

Looks like this bug:

https://issues.dlang.org/show_bug.cgi?id=9279

Has it not been fixed?
March 20, 2017
On Monday, 20 March 2017 at 04:03:20 UTC, Vladimir Panteleev wrote:
> https://issues.dlang.org/show_bug.cgi?id=9279
>
> Has it not been fixed?

That's specific to the return statement. Like you can assign an address of a local variable, but you can't return it.
March 20, 2017
On Thursday, 16 March 2017 at 17:50:45 UTC, Adam D. Ruppe wrote:
> string s = func()[]; // I'd allow it, at least the user wrote `[]` meaning they realized it was stack data and presumably knows what that means about the slice's lifetime

This explicit slice won't work, because a slice of a fixed size array results in a fixed size array.

There's no reason to allow this buggy code though. Also programmer didn't necessarily mean it. It could be a typographic error or a result of refactoring. Even if programmer wanted to write invalid code, what for? Yet this particular code doesn't need to be allowed to allow writing invalid code: one can still cast a number to pointer and do whatever he wants.
March 20, 2017
On Monday, 20 March 2017 at 15:38:26 UTC, Kagamin wrote:
> This explicit slice won't work, because a slice of a fixed size array results in a fixed size array.

No, it doesn't. int[4] a; typeof(a[] == int[])

You can try yourself in the compiler, it is easy to verify.
March 20, 2017
On Monday, 20 March 2017 at 15:46:10 UTC, Adam D. Ruppe wrote:
> On Monday, 20 March 2017 at 15:38:26 UTC, Kagamin wrote:
>> This explicit slice won't work, because a slice of a fixed size array results in a fixed size array.
>
> No, it doesn't. int[4] a; typeof(a[] == int[])
>
> You can try yourself in the compiler, it is easy to verify.

https://dpaste.dzfl.pl/eafa86c5426d
March 20, 2017
On Monday, 20 March 2017 at 16:04:10 UTC, Kagamin wrote:
> https://dpaste.dzfl.pl/eafa86c5426d

Unbelievable, we're both right, sort of.

So it is true that typeof(static[]) == dynamic.

But the language also allows implicit conversion in the other direction.... WTF. If you put a variable in between, it will do a runtime array copy with assert(sizes match), and if the compiler can keep track of where it came from, it will implicitly just make it happen.

So we explicitly sliced... then the compiler implicitly undid it again for overload selection since it knew the size.

This might be the most messed up part of the D language to me now.
March 20, 2017
On 03/20/2017 09:31 AM, Adam D. Ruppe wrote:
> On Monday, 20 March 2017 at 16:04:10 UTC, Kagamin wrote:
>> https://dpaste.dzfl.pl/eafa86c5426d
>
> Unbelievable, we're both right, sort of.
>
> So it is true that typeof(static[]) == dynamic.
>
> But the language also allows implicit conversion in the other
> direction.... WTF. If you put a variable in between, it will do a
> runtime array copy with assert(sizes match), and if the compiler can
> keep track of where it came from, it will implicitly just make it happen.
>
> So we explicitly sliced... then the compiler implicitly undid it again
> for overload selection since it knew the size.
>
> This might be the most messed up part of the D language to me now.

Agreed. Surprisingly, there are quite a number of issues that request exactly that, mostly thanks to our old friend bearophile. The following may be the reason for this WAT:

  https://issues.dlang.org/show_bug.cgi?id=13700

Ali