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

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.

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.

Put your two templates inside of a 3rd mixin template, and instantiate that twice - once for safe, once for not-safe.

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.

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.

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