rval->ref const(T), implicit conversions

bitwise via Digitalmars-d digitalmars-d at puremagic.com
Mon Jan 18 21:43:57 PST 2016


On Tuesday, 19 January 2016 at 04:27:12 UTC, tsbockman wrote:
> On Tuesday, 19 January 2016 at 03:37:17 UTC, tsbockman wrote:
>> It's ten times easier to write code that way, than the way 
>> Manu complained about in the OP.
>
> To clarify:
>
> 1) If `scope` were implemented, Manu's example would look like 
> this:
>     // Declaration
>     void func(in CustomString s1, in CustomString s2);
>
>     // Whenever rvalues need to be passed:
>     func("hello", "world");
>
> 2) With my PR, it looks like this:
>     // Declaration
>     private void funcImpl(ref const(CustomString) s1, ref 
> const(CustomString) s2);
>     mixin acceptRVals!("func", funcImpl);
>
>     // Whenever rvalues need to be passed:
>     func("hello", "world");
>
> 3) Currently, we have this:
>     // Declaration
>     void func(ref const(CustomString) s1, ref 
> const(CustomString) s2);
>
>     // Whenever rvalues need to be passed;
>     auto temp1 = "hello";
>     auto temp2 = "world";
>     func(temp1, temp2);
>
> If A is the number of such functions, B is the number of `ref` 
> arguments per function, and C is the number of calls where 
> rvalues should be passed:
>
> (2) Requires A more statements than (1).
> (3) Requires B*C more statements than (1).
>
> Obviously there is little reason to complain about any of this 
> unless B >= 1 and C > A, so unless I'm missing something, my PR 
> is a large improvement over the status quo.

Sorry if that seemed mean, but it wasn't meant to be insulting. 
But while your solution is clever, I find it totally unrealistic.

Why would anyone use it when they can just templatize their 
function and get exactly the same thing?

struct S{}

void foo(ref const(S) s) {}
becomes
void foo()(auto ref const(S) s) {}

Not to mention the fact that people's first reaction to D's ref 
params not taking rvalues isn't going to be to look in the 
standard library.

Finally, this situation simply should not be this complicated. A 
ref param should accept an rvalue. @safety is a specific concern, 
and unless I'm annotating my code with @safe, I should be able to 
write it however I want(within reason).

To quote a famous author: "Sometimes, an entire community can 
miss a point".

This is one of those points.

Most of my reaction is to the fact that this is actually a 
problem. Sorry I offended you.

     Bit



More information about the Digitalmars-d mailing list