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.
