Thread overview | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
August 04, 2015 dip25 implementation | ||||
---|---|---|---|---|
| ||||
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 |
August 06, 2015 Re: dip25 implementation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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
|
August 06, 2015 Re: dip25 implementation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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?
|
August 06, 2015 Re: dip25 implementation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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.
|
August 06, 2015 Re: dip25 implementation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Per Nordlöw | 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
|
August 06, 2015 Re: dip25 implementation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Xiaoxi | 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
|
August 06, 2015 Re: dip25 implementation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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 |
August 06, 2015 Re: dip25 implementation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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
|
August 07, 2015 Re: dip25 implementation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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
|
Copyright © 1999-2021 by the D Language Foundation