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

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh@quickfur.ath.cx

--

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

Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com

--- Comment #1 from Jonathan M Davis <jmdavisProg@gmx.com> ---
Why just make the implicit slice illegal? Shouldn't it just be illegal to slice it at all, since it's guaranteed to be wrong?

--

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

--- Comment #2 from monarchdodra@gmail.com ---
(In reply to Jonathan M Davis from comment #1)
> Why just make the implicit slice illegal? Shouldn't it just be illegal to slice it at all, since it's guaranteed to be wrong?

I thought about it some more, and there *are* case where you can slice an rvalue static array, provided you've "used" it by the end of the expression. EG:

//----
int sum(int[] i)
{
    return reduce!"a+b"(i);
}

void main()
{
    enum int[3] ints = [1, 2, 3];
    auto s = sum(ints);
}
//----

Here, "ints" is an rvalue static array, and slicing it is legit.

So it appears my initial description of the problem is no accurate. There are times where you can slice an rvalue array.

Not sure where to take this now.
- Do we say "slicing an Rvalue static array is dangerous, and deprecated,
please do it explicitly"?
- Do we find some way to detect *only* the "rvalue static array to dynamic
array assignment" case?
- Give up?

--

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

--- Comment #3 from Jonathan M Davis <jmdavisProg@gmx.com> ---
Well, per issue# 8838, we need to make slicing a static array - implicit or otherwise - @system. As it stands, that's a huge hole in @safe. So, that affects this on some level.

Regardless of whether implicit slicing takes place, I think that if there are any situations where we can statically know that slicing a static array not only unsafe, but it's guaranteed to be wrong, we should make that an error. There's no reason to allow it. I don't know how easy it will be to enumerate those cases and make them errors, but at minimum, as we find them, we should make them errors.

I am 100% convinced that it was a huge mistake to make it so that static arrays are ever implicitly sliced, so I would be very much in favor of deprecating that and move towards removing it from the language, but it would break a lot of code. I think that it's at least similar to the breakage caused by removing implicit fallthrough in that it's highly bug-prone and as such is worth the breakage, but I also don't think that it's wrong in anywhere near as many cases as implicit fallthrough is, so the gain isn't as great. It's also probably far more prevalent in code than switch statements are, so it's likely to be a hard sell. A number of people have already balked at the idea of making slicing static arrays @system even though it's a fact that that has to happen, or we have a whole in @safe - there's no way around that (at best, we _might_ be able to make it @safe in a few cases where scope was used - if scope were fully implemented, which it's not). So, I'd expect a lot of folks to balk at this as well. But I'm convinced that it would be worth it. The question is whether enough people (and in particular, Walter and Andrei) can be convinced of that as well.

But I definitely don't think that we should give up on this in that any case where we know that it's guaranteed to be wrong, it should be an error. There's no reason to allow it aside from the fact that we simply missed that particular case (which should then be fixed when we find it).

--

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

bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc

--- Comment #4 from bearophile_hugs@eml.cc ---
(In reply to monarchdodra from comment #2)

> - Do we find some way to detect *only* the "rvalue static array to dynamic
> array assignment" case?
> - Give up?

Those seem two options. The first introduces a special case.

--

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

Nick Treleaven <ntrel-pub@mybtinternet.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ntrel-pub@mybtinternet.com

--- Comment #5 from Nick Treleaven <ntrel-pub@mybtinternet.com> ---
(In reply to monarchdodra from comment #2)
> I thought about it some more, and there *are* case where you can slice an rvalue static array, provided you've "used" it by the end of the expression.
...
>     enum int[3] ints = [1, 2, 3];
>     auto s = sum(ints);
...
> - Do we find some way to detect *only* the "rvalue static array to dynamic array assignment" case?

Your original example is always wrong:

    int[1] foo();
    int[] a = foo();

Slicing a returned static array should be disallowed by the compiler. Should we rename this issue or file a new one for just this?

--

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

--- Comment #6 from Sobirari Muhomori <dfj1esp02@sneakemail.com> ---
Allow sliced temporary to be passed straight to function parameter (sounds like rvalue reference though), disallow everything else?

--

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

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com
           Severity|normal                      |enhancement

--- Comment #7 from Steven Schveighoffer <schveiguy@yahoo.com> ---
This came up in the newsgroup:
(https://forum.dlang.org/post/xvoisyksvutaaktqaswl@forum.dlang.org)

I think we can say safely that slicing an rvalue return cannot lead to anything good.

As for the example of why it should be allowed, I'm not convinced. That example requires blind faith that the receiver of the slice never does anything bad with it, and assumes the compiler doesn't cleverly reclaim the memory for the rvalue seeing as it wasn't used anywhere. We should reject it for the same reason we reject fun(&generateSomeInt()). Sure, fun may not do anything bad, but it has a lot of leeway to do so.

Not sure how to up the importance of this.

Note, let's not confuse this issue with slicing of a static array that has dedicated stack space (i.e. not a temporary). That may also be rendered an error somehow, but this is vastly more erroneous.

--

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

--- Comment #8 from Sobirari Muhomori <dfj1esp02@sneakemail.com> ---
(In reply to Steven Schveighoffer from comment #7)
> I think we can say safely that slicing an rvalue return cannot lead to anything good.
> 
> As for the example of why it should be allowed, I'm not convinced.

tempCString is another example of an rvalue reference. Works good so far.

> example requires blind faith that the receiver of the slice never does anything bad with it, and assumes the compiler doesn't cleverly reclaim the memory for the rvalue seeing as it wasn't used anywhere.

If the temporary isn't used, it should be reclaimed.

--

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

--- Comment #9 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Sobirari Muhomori from comment #8)
> tempCString is another example of an rvalue reference. Works good so far.

Another good example of an error waiting to happen:

char *str = someString.tempCString;

This would be more difficult for the compiler to figure out, because the address-taking is done inside a method.

tempCString also has a destructor, so pushing the destruction of the temporary to after the expression is actually easier to mandate/do.

> 
> > example requires blind faith that the receiver of the slice never does anything bad with it, and assumes the compiler doesn't cleverly reclaim the memory for the rvalue seeing as it wasn't used anywhere.
> 
> If the temporary isn't used, it should be reclaimed.

What are the rules for temporaries that aren't further used in the expression? In this case, the result of foo isn't passed into another function, just a slice is.

I suppose if the rules mandate any temporaries live until after the expression is completed, then we don't need to worry about the memory being reclaimed mid expression. We are then just left with the issue of assigning a pointer that points at the temporary. How to figure out generally that this is the case? Not sure.

IMO, however, the original problem (assigning a slice of a temporary) should be easy to flag, since the compiler understands what is happening, and knows that it is obviously invalid.

--