On 9/25/20 11:13 AM, 60rntogo wrote:
> On Friday, 25 September 2020 at 14:21:59 UTC, Steven Schveighoffer wrote:
>> in does not mean "take by reference", it means "scope const"
> 
> I'm not sure that I really understand scope, but I read https://dlang.org/spec/function.html#param-storage as saying "in means take by value or reference depending on what is better optimized". Is that not what we want here?

That's new, unreleased (available in 2.094.0), and requires the -preview=in switch. I wouldn't depend on that mechanism yes.

> Right, again I'm wondering if there is a way of saying "just figure out if it's more optimal to return by value or const reference".

If the input is not ref, you should not return by ref, because then you would be returning a reference to local stack data that is about to be destroyed.

The only way to say "make this const ONLY if it's ref" is to overload the function with the proper attributes for the proper situations.

Otherwise, you can just return const auto ref.

-Steve

On 9/25/20 11:21 AM, Steven Schveighoffer wrote:
> I wouldn't depend on that mechanism yes.

*yet*.

-Steve

On Friday, 25 September 2020 at 15:21:22 UTC, Steven Schveighoffer wrote:
> If the input is not ref, you should not return by ref, because then you would be returning a reference to local stack data that is about to be destroyed.

Yes, I understand that. What I'm really after at this point is that I would like to write a clever mixin that would handle all of these decisions for me. It should generate a function that takes arguments and returns the result by value or const reference depending on what is more appropriate for the given types. I was under the impression that this could be accomplished using in or some other qualifiers.

On Fri, Sep 25, 2020 at 05:58:08PM +0000, 60rntogo via Digitalmars-d-learn wrote:
> On Friday, 25 September 2020 at 15:21:22 UTC, Steven Schveighoffer wrote:
> > If the input is not ref, you should not return by ref, because then you would be returning a reference to local stack data that is about to be destroyed.
> 
> Yes, I understand that. What I'm really after at this point is that I would like to write a clever mixin that would handle all of these decisions for me. It should generate a function that takes arguments and returns the result by value or const reference depending on what is more appropriate for the given types. I was under the impression that this could be accomplished using in or some other qualifiers.

You probably need to use the long-form of templates, with separate function declarations, to accomplish this. E.g.:

	template myFunc(Args...) {
		static if (shouldReturnByRef!Args)
			ref ReturnType myFunc(Args args) {
				... // implementation here
			}
		else // non-ref return
			ReturnType myFunc(Args args) {
				... // implementation here
			}
	}

The reason is that `ref` return is an attribute of the *function*, not the return type, so you can't just use an `auto` return type and have the compiler infer it.


T

-- 
What doesn't kill me makes me stranger.

On Friday, 25 September 2020 at 18:58:54 UTC, H. S. Teoh wrote:
> You probably need to use the long-form of templates, with separate function declarations, to accomplish this. E.g.:
>
> ...

Alright, but your example still contains shouldReturnByRef which presumably I need to implement myself. But that's an optimization detail that I'd rather leave up to the compiler, is that possible?