On Thursday, 6 August 2015 at 21:18:13 UTC, Steven Schveighoffer wrote:
On 8/6/15 4:11 PM, Xiaoxi wrote:
On Thursday, 6 August 2015 at 19:55:20 UTC, Steven Schveighoffer wrote:
On 8/4/15 4:54 PM, Steven Schveighoffer wrote:
How complete is the dip25 implementation?

For example, should this be expected to be an error?

struct S
{
   int[5] x;
   auto foo() { return x[];}
}

I'll note, that dmd 2.067.0 with -dip25 considered this an error, head does not. Adding a 'return' to the foo attributes fixes it in 2.067,
but...

auto getS()
{
    S s;
    return s.foo();
}

does not error in either version, even with the return attribute.

Anyone? Is this a bug or not?


why is it related to dip25? slices uses pointers not ref?

I think it's because the 'this' is implicitly ref.

I'm not sure why that would matter though, since you're returning a dynamic array in foo - and thus in getS - so there is no ref involved. It's unsafe, because that dynamic array is a slice of a static array, but no ref is being returned - and no ref is being passed in - so DIP 25 shouldn't apply.

If dip25 just throws its hands up on slicing, it has a problem I think.

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

On a related note, it would be great if we didn't have implicit slicing of static arrays, but I expect that that boat of doom has long since sailed... :(

In any case, 2.067 complained about it with -dip25, and didn't without, so it seems related.

Well, DIP 25 itself says nothing about arrays at all, let alone the slicing of static arrays. So, I don't know why 2.067 would have given an error like it does. My first guess would be that it was a bug in its implementation of -dip25, but I don't know.

- Jonathan M Davis

Reply via email to