On Wed, Oct 27, 2021 at 07:19:31PM +0000, Dukc via Digitalmars-d wrote: [...]
> ```d
> pure short coming()
> { typeof(return) result = void;
>   return result; //may return anything
> }
> ```
> 
> But when you think of it, why should this be a problem? This one returns an implementation defined value. If a compiler skips repeated calls to this one because of the `pure` attribute and just reuses the value from the first call, so what? Because the return values are implementation defined, the compiler is free to have them all to be the same with regards to each other.

Returning a void-initialized (i.e., *un*initialized) result invokes UB.
The compiler is free to do (or not do) whatever it wants in this case.


T

-- 
Only boring people get bored. -- JM

On Wednesday, 27 October 2021 at 19:31:52 UTC, H. S. Teoh wrote:
>
> Returning a void-initialized (i.e., *un*initialized) result invokes UB.
> The compiler is free to do (or not do) whatever it wants in this case.
>
>
> T

Only if the result contains pointers. With other types, the result is undefined but not the rest of the program.

On Wed, Oct 27, 2021 at 07:26:57PM +0000, IGotD- via Digitalmars-d wrote:
> On Wednesday, 27 October 2021 at 19:19:31 UTC, Dukc wrote:
> > 
> > `pure` is also supposed to be an optimization aid.
> 
> It would be interesting to see an example of how pure can help optimization, compared to if you wouldn't badge the function.

The following example supposedly shows the difference:

	int pureFunc() pure { return 1; }
	int impureFunc() { return 1; }
	void main() {
		writeln(pureFunc() + pureFunc()); // compiler may call pureFunc only once
		writeln(impureFunc() + impureFunc()); // compiler must call impureFunc twice
	}

Unfortunately, a quick test with dmd did not show the expected optimization.  Which confirms what I said before that pure's optimization benefit is really rather marginal.

The bigger benefit is the mechanical verification that you didn't accidentally depend on global state when you didn't want to, which can help with improving code quality.


T

-- 
Which is worse: ignorance or apathy? Who knows? Who cares? -- Erich Schubert

On Wed, Oct 27, 2021 at 07:40:10PM +0000, Dukc via Digitalmars-d wrote:
> On Wednesday, 27 October 2021 at 19:31:52 UTC, H. S. Teoh wrote:
> > 
> > Returning a void-initialized (i.e., *un*initialized) result invokes
> > UB.  The compiler is free to do (or not do) whatever it wants in
> > this case.
[...]
> Only if the result contains pointers. With other types, the result is undefined but not the rest of the program.

Right, but the result being undefined means the compiler is free to cache or not cache the return value without violating the spec.


T

-- 
"Holy war is an oxymoron." -- Lazarus Long

On Wednesday, 27 October 2021 at 19:53:52 UTC, H. S. Teoh wrote:
> The bigger benefit is the mechanical verification that you didn't accidentally depend on global state when you didn't want to, which can help with improving code quality.

It could if "pure" was default and you had to type "uses_globals" if you went past that. Adding pure all over the place is just too tedious and visually annoying.

On Wednesday, 27 October 2021 at 19:40:10 UTC, Dukc wrote:
> On Wednesday, 27 October 2021 at 19:31:52 UTC, H. S. Teoh wrote:
>>
>> Returning a void-initialized (i.e., *un*initialized) result invokes UB.
>> The compiler is free to do (or not do) whatever it wants in this case.
>>
>>
>> T
>
> Only if the result contains pointers. With other types, the result is undefined but not the rest of the program.

According to the current language spec, the entire program has undefined behavior whether or not the result contains pointers. Walter has proposed to change this [1], but the proposal has not been accepted.

[1]: https://github.com/dlang/dlang.org/pull/2260