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.

-Steve

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?

-Steve

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?
>
> -Steve

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

On Tuesday, 4 August 2015 at 20:54:43 UTC, 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[];}
> }

You need to (at least) qualify `foo` as @safe.

On 8/6/15 4:24 PM, "Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow@gmail.com>" wrote:
> On Tuesday, 4 August 2015 at 20:54:43 UTC, 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[];}
>> }
>
> You need to (at least) qualify `foo` as @safe.

According to 2.067.0 it was an error without annotating as @safe if you use -dip25. I don't understand the "relaxing" of it in the latest version, but maybe I'm missing something.

If x was a function local, you don't need to mark foo @safe to get an error. I thought dip25 was supposed to make that the norm for all data that it could prove was being improperly escaped.

-Steve

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. If dip25 just throws its hands up on slicing, it has a problem I think.

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

-Steve

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

On Thursday, 6 August 2015 at 21:16:20 UTC, Steven Schveighoffer wrote:
> On 8/6/15 4:24 PM, "Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow@gmail.com>" wrote:
>> On Tuesday, 4 August 2015 at 20:54:43 UTC, 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[];}
>>> }
>>
>> You need to (at least) qualify `foo` as @safe.
>
> According to 2.067.0 it was an error without annotating as @safe if you use -dip25. I don't understand the "relaxing" of it in the latest version, but maybe I'm missing something.
>
> If x was a function local, you don't need to mark foo @safe to get an error. I thought dip25 was supposed to make that the norm for all data that it could prove was being improperly escaped.

Per DIP 25, it's only supposed to apply to @safe code initially:

"For the initial release, the requirement of returns for ref parameter data to be marked with return will only apply to @safe functions. The reasons for this are to avoid breaking existing code, and because it's not yet clear whether this feature will interfere with valid constructs in a system language."

So, it was a bug in 2.067 if it required anything with -dip25 for @system or @trusted code.

- Jonathan M Davis

On Thursday, 6 August 2015 at 21:16:20 UTC, Steven Schveighoffer wrote:
> On 8/6/15 4:24 PM, "Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow@gmail.com>" wrote:
>> On Tuesday, 4 August 2015 at 20:54:43 UTC, 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[];}
>>> }
>>
>> You need to (at least) qualify `foo` as @safe.
>
> According to 2.067.0 it was an error without annotating as @safe if you use -dip25. I don't understand the "relaxing" of it in the latest version, but maybe I'm missing something.
>

auto functions now trigger inferance