DIP 1016--ref T accepts r-values--Formal Assessment
SeeWebsiteForEmail at erdani.com
Mon Jan 28 18:00:38 UTC 2019
On 1/24/19 3:01 PM, 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. ;)
It seems to me that a proposal adding the "@rvalue" attribute in
function signatures to each parameter that would accept either an rvalue
or an lvalue would be easy to argue.
- No exposing existing APIs to wrong uses
- The function's writer makes the decision ("I'm fine with this function
taking an rvalue")
- Appears in the function's documentation
- Syntax is light and localized where it belongs
- Scales well with number of parameters
- Transparent to callers
Whether existing keyword combinations ("in", "out", "ref" etc) could be
used is a secondary point.
The advantage is there's a simple and clear path forward for API
definition and use.
More information about the Digitalmars-d-announce