www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Time to start compiling with -dip25

reply Walter Bright <newshound2 digitalmars.com> writes:
As it's going to become the default behavior. Maybe not in the next release,
but 
soon.

Here are some examples of how to upgrade your code, is usually means adding 
`return` here and there.

https://github.com/dlang/dmd/pull/9154
Dec 28 2018
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 12/28/2018 5:08 PM, Walter Bright via Digitalmars-d wrote:
 As it's going to become the default behavior. Maybe not in the next 
 release, but soon.
 
 Here are some examples of how to upgrade your code, is usually means 
 adding `return` here and there.
 
 https://github.com/dlang/dmd/pull/9154
Insert url with updated specifications <here>. "Here and there" is entirely non-specific and unhelpful.
Dec 28 2018
parent reply Tony <tonytdominguez aol.com> writes:
https://github.com/dlang/DIPs/blob/master/DIPs/archive/DIP25.md

Sealed references
In a nutshell
This DIP proposes that any ref parameter that a function 
received and also wants to
return must be also annotated with return. Annotation are 
deduced for templates and
lambdas, but must be explicit for all other declarations.
Example:
 safe:
ref int fun(ref int a) { return a; } // ERROR
ref int gun(return ref int a) { return a; } // FINE
ref T hun(T)(ref T a) { return a; } // FINE, templates use 
deduction
Dec 28 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/28/2018 11:19 PM, Tony wrote:
 https://github.com/dlang/DIPs/blob/master/DIPs/archive/DIP25.md
Also: https://dlang.org/spec/function.html#return-ref-parameters
Dec 29 2018
parent reply Daniel N <no public.email> writes:
On Saturday, 29 December 2018 at 08:32:21 UTC, Walter Bright 
wrote:
 On 12/28/2018 11:19 PM, Tony wrote:
 https://github.com/dlang/DIPs/blob/master/DIPs/archive/DIP25.md
Also: https://dlang.org/spec/function.html#return-ref-parameters
Awesome news! One question, classes, in particular when combined with typesafe_variadic_functions seems to break safe, unless DIP25 style return annotation is added. "An implementation may construct the object or array instance on the stack. Therefore, it is an error to refer to that instance after the variadic function has returned" https://dlang.org/spec/function.html#typesafe_variadic_functions Is this something which should be addressed by DIP25 or it is out of scope? void main() { auto x1 = fun(1); auto x2 = fun(2); import std.stdio; writeln(x1.a, x2.a); } safe: class C { public: int a; this(int a) { this.a = a; } } C fun(/* return */ C c...) { return c; }
Dec 29 2018
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/29/2018 3:16 AM, Daniel N wrote:
 Is this something which should be addressed by DIP25 or it is out of scope?
Regardless of whether it is DIP25, DIP1000, whatever, if you find a case where a garbage pointer can be de-referenced in safe code, please file a bug report!
Dec 29 2018
prev sibling parent Nick Treleaven <nick geany.org> writes:
On Saturday, 29 December 2018 at 11:16:01 UTC, Daniel N wrote:
| typesafe_variadic_functions seems to break safe,

DIP 25 only affects ref parameters, DIP 1000 does apply.

I think this is:
https://issues.dlang.org/show_bug.cgi?id=5212
Dec 30 2018
prev sibling next sibling parent reply Ron Tarrant <rontarrant gmail.com> writes:
On Saturday, 29 December 2018 at 01:08:32 UTC, Walter Bright 
wrote:
 As it's going to become the default behavior. Maybe not in the 
 next release, but soon.
Under what circumstances would this be used? (D-newbie here)
Dec 30 2018
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/30/2018 5:41 AM, Ron Tarrant wrote:
 Under what circumstances would this be used? (D-newbie here)
Under all circumstances, i.e. it would be a fundamental part of the language.
Dec 30 2018
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Dec 28, 2018 at 05:08:32PM -0800, Walter Bright via Digitalmars-d wrote:
 As it's going to become the default behavior. Maybe not in the next
 release, but soon.
 
 Here are some examples of how to upgrade your code, is usually means
 adding `return` here and there.
 
 https://github.com/dlang/dmd/pull/9154
So, today I decided to take a shot at testing one of my smaller projects with -dip25. It appears that -dip25 really only has a real effect when in safe code, so I tried marking my code safe. Unfortunately, it has been an exceptionally frustrating experience and I have run into a roadblock: I have a pair of mutually-recursive template functions: auto func1(R)(R range) { ... range.func2(); ... } auto func2(R)(R range) { ... range.func1(); ... } Unsurprisingly, the compiler was unable to infer safe for these functions, since their mutual dependency understandably makes it hard for automatic inference to deduce safe correctly. However, there is no workaround for this that I know of: I cannot mark these functions as safe because *sometimes* I need to call them with R = a system type, primarily std.stdio.ByLine -- why that is not safe is a can of worms I'm not sure I want to open right now; but the bottom line is, sometimes R needs to be a system type, but there is currently no nice way in the language to express the concept "this template function is safe unless template argument R is system". This is an impasse that hinders further progress, so at this point, I have no choice but to give up on making more of my code safe. Which also means, as far as I'm concerned, that -dip25 is worth almost nothing to me right now. :-( T -- Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln
Dec 31 2018
parent Walter Bright <newshound2 digitalmars.com> writes:
Put your two templates inside of a 3rd mixin template, and instantiate that 
twice - once for safe, once for not-safe.
Jan 01 2019
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Dec 31, 2018 at 04:36:29PM -0800, H. S. Teoh via Digitalmars-d wrote:
[...]
 	auto func1(R)(R range)
 	{
 		...
 		range.func2();
 		...
 	}
 
 	auto func2(R)(R range)
 	{
 		...
 		range.func1();
 		...
 	}
 
 Unsurprisingly, the compiler was unable to infer  safe for these
 functions, since their mutual dependency understandably makes it hard
 for automatic inference to deduce  safe correctly.
[...] Apparently there's already an issue for this: https://issues.dlang.org/show_bug.cgi?id=16528 It's been 3 years since this was filed. :-( T -- "A man's wife has more power over him than the state has." -- Ralph Emerson
Dec 31 2018
parent Jusl <jusl gmail.usa> writes:
On Tuesday, 1 January 2019 at 00:48:47 UTC, H. S. Teoh wrote:
 On Mon, Dec 31, 2018 at 04:36:29PM -0800, H. S. Teoh via 
 Digitalmars-d wrote: [...]
 	auto func1(R)(R range)
 	{
 		...
 		range.func2();
 		...
 	}
 
 	auto func2(R)(R range)
 	{
 		...
 		range.func1();
 		...
 	}
 
 Unsurprisingly, the compiler was unable to infer  safe for 
 these functions, since their mutual dependency understandably 
 makes it hard for automatic inference to deduce  safe 
 correctly.
[...] Apparently there's already an issue for this: https://issues.dlang.org/show_bug.cgi?id=16528 It's been 3 years since this was filed. :-( T
Classic D. -> File a bug report! -> One has already existed for years. Ducking classic.
Dec 31 2018
prev sibling parent reply Johan Engelen <j j.nl> writes:
On Saturday, 29 December 2018 at 01:08:32 UTC, Walter Bright 
wrote:
 As it's going to become the default behavior. Maybe not in the 
 next release, but soon.
Let me add some data points to the discussion using Weka's complex codebase [1]. To make compilation succeed with DIP25, I had to add `return` to a function or parameter 48 times. That's much less than I was expecting. I didn't encounter any problems otherwise (dlang 2.083.1 frontend). Error messages are OK for the compiler expert, but need improvement: the error message points to the return statement where something is "leaked", e.g.: "mecca/lib/reflection.d(1028): Error: returning `this.a` escapes a reference to parameter `this`, perhaps annotate with `return`" It's not clear that `return` needs to be added as function attribute. Also, mentioning escaping a reference to "this" is confusing and (in some interpretations) incorrect. How about mentioning something along the lines of "escapes a reference to member field `this.a`". Also, a reference to DIP25 must be made, such that people can find documentation more easily (just addition of "(DIP25)" would already be a big improvement). The required additions of `return` are soon up for code review. I didn't find any bugs with it (nor was I expecting to). I want Weka's code owners to be aware of DIP25 and verify that indeed that's what they intended in their code (I think the returning of slices of member arrays is least obvious to spot when data should outlive the object). -Johan [1] https://dlang.org/blog/2018/12/04/interview-liran-zvibel-of-wekaio/ Weka's codebase is interesting: 280 kloc, _many_ templates + mixins + static ifs, separate compilation, dirty pointer tricks in system code but also many safe parts.
Jan 01 2019
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/1/2019 10:38 AM, Johan Engelen wrote:
 [...]
It would be nice to file bugzilla issues with specific pieces of code that cause particular error messages, along with the suggested improved one. This is particularly helpful, because it can be hard to guess at the context of what produces a particular error, and the same message can make perfect sense in one context but not in another.
Jan 01 2019
prev sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Tuesday, 1 January 2019 at 18:38:57 UTC, Johan Engelen wrote:
 [..]

 Let me add some data points to the discussion using Weka's 
 complex codebase [1].

 To make compilation succeed with DIP25, I had to add `return` 
 to a function or parameter 48 times. That's much less than I 
 was expecting. I didn't encounter any problems otherwise (dlang 
 2.083.1 frontend).

 [..]
Hi Johan and happy new year :) I don't know if you are aware, but I opened a pull request fixing compilation with -dip25 a couple of days ago: https://github.com/weka-io/mecca/pull/13 WekaIO's mecca being open-source and recongized as one of the important projects for the community (its actual usefulness for the company notwithstanding), and so being part of the list of projects tested on BuildKite (aka the project tester), gives it a chance to receive more attention from developers from the wider D community. I'm sure that internally Weka has a rigorous code review and testing processes in place, perhaps not comparable to what a free GitHub + CI service like Travis can provide, but I'd like to suggest that people from the community can help the team as sometimes we're aware of certain language changes months before official releases, and can help you in upgrading to newer compiler releases. (Not that we're in possession of some secret information, on the contrary, but not always people on their day job have enough time to keep track of happenings elsewhere.) I know that upgrading to a new compiler release is a much more involved process, but I believe we can help nonetheless.
Jan 02 2019
parent Johan Engelen <j j.nl> writes:
On Wednesday, 2 January 2019 at 19:20:41 UTC, Petar Kirov 
[ZombineDev] wrote:
 On Tuesday, 1 January 2019 at 18:38:57 UTC, Johan Engelen wrote:
 [..]

 Let me add some data points to the discussion using Weka's 
 complex codebase [1].

 To make compilation succeed with DIP25, I had to add `return` 
 to a function or parameter 48 times. That's much less than I 
 was expecting. I didn't encounter any problems otherwise 
 (dlang 2.083.1 frontend).

 [..]
Hi Johan and happy new year :) I don't know if you are aware, but I opened a pull request fixing compilation with -dip25 a couple of days ago: https://github.com/weka-io/mecca/pull/13
Best wishes for you too :-) I wasn't aware of your PR, thanks for the heads up. Cheers, Johan
Jan 02 2019