digitalmars.D - dip25 implementation
- Steven Schveighoffer (16/16) Aug 04 2015 How complete is the dip25 implementation?
- Steven Schveighoffer (3/18) Aug 06 2015 Anyone? Is this a bug or not?
- Xiaoxi (3/29) Aug 06 2015 why is it related to dip25? slices uses pointers not ref?
- Steven Schveighoffer (6/33) Aug 06 2015 I think it's because the 'this' is implicitly ref. If dip25 just throws
- Jonathan M Davis (16/54) Aug 06 2015 I'm not sure why that would matter though, since you're returning
- "Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow gmail.com> (3/10) Aug 06 2015 You need to (at least) qualify `foo` as @safe.
- Steven Schveighoffer (9/20) Aug 06 2015 According to 2.067.0 it was an error without annotating as @safe if you
- Jonathan M Davis (11/33) Aug 06 2015 Per DIP 25, it's only supposed to apply to @safe code initially:
- Xiaoxi (3/21) Aug 07 2015 auto functions now trigger inferance
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
Aug 04 2015
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
Aug 06 2015
On Thursday, 6 August 2015 at 19:55:20 UTC, Steven Schveighoffer wrote:On 8/4/15 4:54 PM, Steven Schveighoffer wrote:why is it related to dip25? slices uses pointers not ref?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
Aug 06 2015
On 8/6/15 4:11 PM, Xiaoxi wrote:On Thursday, 6 August 2015 at 19:55:20 UTC, Steven Schveighoffer wrote: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. -SteveOn 8/4/15 4:54 PM, Steven Schveighoffer wrote:why is it related to dip25? slices uses pointers not ref?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?
Aug 06 2015
"Jonathan M Davis" <jmdavisProg gmx.com> On Thursday, 6 August 2015 at 21:18:13 UTC, Steven Schveighoffer wrote:On 8/6/15 4:11 PM, Xiaoxi wrote: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.On Thursday, 6 August 2015 at 19:55:20 UTC, Steven Schveighoffer wrote:I think it's because the 'this' is implicitly ref.On 8/4/15 4:54 PM, Steven Schveighoffer wrote:why is it related to dip25? slices uses pointers not ref?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?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
Aug 06 2015
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.
Aug 06 2015
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: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. -SteveHow 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.
Aug 06 2015
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: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 DavisOn Tuesday, 4 August 2015 at 20:54:43 UTC, Steven Schveighoffer wrote: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.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.
Aug 06 2015
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:auto functions now trigger inferanceOn Tuesday, 4 August 2015 at 20:54:43 UTC, Steven Schveighoffer wrote: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.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.
Aug 07 2015