DIP 1016--ref T accepts r-values--Formal Assessment

Rubn where at is.this
Thu Jan 24 21:57:57 UTC 2019


On Thursday, 24 January 2019 at 20:01:45 UTC, kinke wrote:
> On Thursday, 24 January 2019 at 09:49:14 UTC, Manu wrote:
>> We discussed and concluded that one mechanism to mitigate this 
>> issue
>> was already readily available, and it's just that 'out' gains 
>> a much
>> greater sense of identity (which is actually a positive 
>> side-effect if
>> you ask me!).
>> You have a stronger motivation to use 'out' appropriately, 
>> because it
>> can issue compile errors if you accidentally supply an rvalue.
>
> `out` with current semantics cannot be used as drop-in 
> replacement for shared in-/output ref params, as `out` params 
> are default-initialized on entry. Ignoring backwards 
> compatibility for a second, I think getting rid of that would 
> actually be beneficial (most args are probably already 
> default-initialized by the callee in the line above the 
> call...) - and I'd prefer an explicitly required `out` at the 
> call site (C# style), to make the side effect clearly visible.
>
> I'd have otherwise proposed a `@noRVal` param UDA, but 
> redefining `out` is too tempting indeed. ;)

Yah I'd like this approach way better and it could be an error if 
the function didn't assign the variable a value instead. Rather 
than just default initializing it.

void test(out int value) {
     // error: value must be assigned a value
}

In the event the value passed isn't initialized. Can be dangerous 
if it is a struct with a destructor though. If they void 
initialized it, but I guess that's a problem with the current 
implementation as well.


More information about the Digitalmars-d-announce mailing list