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

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.

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

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

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;
}

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!

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

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)

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.

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