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