Jump to page: 1 215  
Page
Thread overview
DIP 1016--ref T accepts r-values--Formal Assessment
Jan 24
kinke
Jan 24
Manu
Jan 25
kinke
Jan 25
kinke
Jan 26
Manu
Jan 26
Manu
Jan 24
Manu
Jan 24
kinke
Jan 24
kinke
Jan 24
Rubn
Jan 24
kinke
Jan 24
Manu
Jan 24
kinke
Jan 24
Rubn
Jan 24
Manu
Jan 29
Manu
Jan 30
kinke
Jan 24
Rubn
Jan 24
Manu
Jan 24
Manu
Jan 25
Manu
Jan 25
Dein
Jan 25
Manu
Jan 25
Manu
Jan 24
Dgame
Jan 25
Rubn
Jan 26
Manu
Jan 26
Rubn
Jan 29
Manu
Jan 26
Manu
Jan 29
Manu
Jan 30
Manu
Jan 30
Manu
Jan 31
Manu
Jan 31
Manu
Jan 31
Manu
Jan 31
jmh530
Jan 31
jmh530
Jan 31
Rubn
Jan 31
jmh530
Feb 01
jmh530
Feb 01
aliak
Feb 01
aliak
Feb 01
Aliak
Jan 31
Manu
Jan 31
Manu
Jan 30
Don
Jan 30
Don
Jan 30
Don
Feb 04
bitwise
Feb 04
bitwise
Feb 08
bitwise
Feb 08
Dennis
Feb 09
Dennis
Feb 09
bitwise
Feb 10
Daniel N
January 24
Walter and Andrei have declined to accept DIP 1016, "ref T accepts r-values", on the grounds that it has two fundamental flaws that would open holes in the language. They are not opposed to the feature in principle and suggested that a proposal that closes those holes and covers all the bases will have a higher chance of getting accepted.

You can read a summary of the Formal Assessment at the bottom of the document:

https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md
January 24
On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
> Walter and Andrei have declined to accept DIP 1016, "ref T accepts r-values", on the grounds that it has two fundamental flaws that would open holes in the language. They are not opposed to the feature in principle and suggested that a proposal that closes those holes and covers all the bases will have a higher chance of getting accepted.
>
> You can read a summary of the Formal Assessment at the bottom of the document:
>
> https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md

>> fun(10)
>> ==>
>> {
>>  T __temp0 = void;
>>  fun(__temp0 := 10);
>> }
> The first problem the Language Maintainers identified with this approach is that the rewrite is from an expression to a statement, rendering it invalid.
> The expression should be rewritten as an expression to clarify how it behaves in larger expressions.

But it does, or at least gives an example of: https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md#function-calls-as-arguments

The statement the expression is part of is "enscoped" and the temporaries live in the scope of that statement.
January 24
On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
> Walter and Andrei have declined to accept DIP 1016, "ref T accepts r-values", on the grounds that it has two fundamental flaws that would open holes in the language. They are not opposed to the feature in principle and suggested that a proposal that closes those holes and covers all the bases will have a higher chance of getting accepted.
>
> You can read a summary of the Formal Assessment at the bottom of the document:
>
> https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md

> The second problem is the use of := (which the DIP Author defines as representing "the initial construction, and not a copy operation as would be expected if this code were written with an = expression"). This approach shows its deficiencies in the multiple arguments case; if the first constructor throws an exception, all remaining values will be destroyed in the void state as they never have the chance to become initialized.

Although not specified by the DIP, I think this could be easily remedied by saying that the order of construction is the same as if the temporaries were not bound to ref, i.e.

---
struct A {~this();} struct B{ ~this();}
A a();
B b();

void f(A a, B b);
void g(ref A a, ref B b);

f(a(),b());  //(1)
g(a(),b()); //(2)
---

and a() or b() may throw (and are pure), that (1) and (2) exhibit the same exception/destructor semantics.

Which is what I would expect to happen under no given specification (although specifying it is a good idea!). To put it another way, they should be constructed in place in the order they are used, and given they are a temporary, they can only be used once.

January 24
On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
> Walter and Andrei have declined to accept DIP 1016, "ref T accepts r-values", on the grounds that it has two fundamental flaws that would open holes in the language. They are not opposed to the feature in principle and suggested that a proposal that closes those holes and covers all the bases will have a higher chance of getting accepted.
>
> You can read a summary of the Formal Assessment at the bottom of the document:
>
> https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md

> void atomicIncrement(ref shared long x);
> atomicIncrement(myInt);

Raises a good point, not covered by @disable where the intent is to modify it and modifying a temporary is wrong. `out ref` perhaps?
January 24
Hooray!
Who didn't see that coming 10 years off!

I understand the criticism, the most critical issue seems relatively
trivial and easy to patch (initialisation order), but this comment is
a problem for me "However, this proposal does not maintain the
distinction and instead conflates the two cases".
It's not like that's an accident, or I didn't think of this. The whole
point of this proposal is to lift an arbitrary restriction, thereby
achieving the 2 use cases stated on the opening paragraph, and
increasing language uniformity by removing edges.
"Maintaining the distinction" assumes an approach that is not lifting
one restriction and thereby creating greater uniformity in the
language, but rather, creating 2 more distinct sources of rules, and
that's not attractive as a solution space at all. We've talked about
solutions to this problem that involve adding more rules extensively,
and they're not satisfying.
So it's not because I'm an idiot that I conflated them, it's because
that's literally the point.

Then there's this one:
"The first problem the Language Maintainers identified with this
approach is that the rewrite is from an expression to a statement,
rendering it invalid"
And then present this snippet:
```
fun(10)
==>
{
  T __temp0 = void;
  fun(__temp0 := 10);
}
```
I'm upset by this comment, because it's almost like a deliberate
misrepresentation...
Not only did I never suggest anywhere that the intent is to translate
an expression into a statement, but the following examples demonstrate
why it's expanded that way with more complex compound statements, ie:
```
void fun(ref int x, ref int y);
int gun(ref int x);

fun(10, gun(20));  // <- clearly a statement
```
But even the simplest form introduced first (and presented as
evidence) DOES HAVE A SEMICOLON on the end in my DIP, but removed from
the review?
So I can't agree with this comment: "The expression should be
rewritten as an expression to clarify how it behaves in larger
expressions."; this whole thing is about statements, not expressions.
Misunderstanding that is to misunderstand the proposal entirely.

So my feeling is that this initial point "First, reasoning about the
proposed semantics is futile, as they are built upon a flawed
foundation" is just plain invalid, the suggestion I'm talking about
expressions is incorrect.
And that invalidates this second point "Second,reasoning about the
consequences of potentially revised semantics is equivalent to
considering a new DIP."
I think it's possible to consider this DIP, but the suggestion is that
something other than what I wrote is what has been considered.

Anyway, I can only blame myself for somehow failing to communicate these details, although I don't know how I managed that.

The criticism about initialisation ordering is absolutely fair, and I suspect it requires a small amount of tweaking (perhaps initialising eagerly, or rather just expanding the code and ordering/sequencing the expansion a little more carefully), to address the throwing-an-exception mid-statement issue, and not an entirely different DIP written by someone competent like Timon.

I think all of that is mostly just fluff to lend weight to this
critical sentence "The Language Maintainers insist that any proposal
allowing ref parameters to accept rvalue references must clearly
define how functions which make use of ref for side effects will not
accept rvalues."
And that's 'just like, your opinion man'. A key point is for functions
that do side-effects to receive rvalues too, and this was arrived at
after much community discussion. We identified real cases where we
*want* functions that receive rvalues to do side-effects,
specifically, UFCS chains are frequently broken by need to capture an
lvalue mid-steam.
Pipeline programming is a big deal, and improving that experience was
a motivator for this proposal.

This process is pretty unsatisfying, because it ships off to a black-box committee, who were apparently able to misunderstand the substance of the proposal and then not seek clarification, and despite the only legitimate issue from my perspective being easily corrected, it's been suggested to start a whole new DIP.

On Wed, Jan 23, 2019 at 11:20 PM Mike Parker via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> Walter and Andrei have declined to accept DIP 1016, "ref T accepts r-values", on the grounds that it has two fundamental flaws that would open holes in the language. They are not opposed to the feature in principle and suggested that a proposal that closes those holes and covers all the bases will have a higher chance of getting accepted.
>
> You can read a summary of the Formal Assessment at the bottom of the document:
>
> https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md
January 24
On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
> Walter and Andrei have declined to accept DIP 1016, "ref T accepts r-values", on the grounds that it has two fundamental flaws that would open holes in the language. They are not opposed to the feature in principle and suggested that a proposal that closes those holes and covers all the bases will have a higher chance of getting accepted.
>
> You can read a summary of the Formal Assessment at the bottom of the document:
>
> https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md

> [Reasons]. As such, they suggest that a new DIP be drafted from scratch, and that a stronger proposal would have a better chance of acceptance.

Given the simplicity of the fixes for the problems identified I really don't think thats the best way forward. One round of forum review + formal reassessment ought to be enough.
January 24
On Thu, Jan 24, 2019 at 1:25 AM Nicholas Wilson via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
> > Walter and Andrei have declined to accept DIP 1016, "ref T accepts r-values", on the grounds that it has two fundamental flaws that would open holes in the language. They are not opposed to the feature in principle and suggested that a proposal that closes those holes and covers all the bases will have a higher chance of getting accepted.
> >
> > You can read a summary of the Formal Assessment at the bottom of the document:
> >
> > https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md
>
> > void atomicIncrement(ref shared long x);
> > atomicIncrement(myInt);
>
> Raises a good point, not covered by @disable where the intent is to modify it and modifying a temporary is wrong. `out ref` perhaps?

Actually, this was discussed, but somehow this piece of discussion didn't get folded back it to the DIP. It is mentioned in the 'Community Review Round 1' digest though.

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.

That doesn't address the specific `atomicIncrement` case here, but now
we're in VERY niche territory; we analysed a lot of cases, and
concluded that such cases were relatively few, and other choices exist
to mitigate those cases.
There are cases that want to do mutation to rvalues (like in pipeline
functions), and then most cases can use 'out' instead. Remaining cases
are quite hard to find, and in this particular case, I'd suggest that
`atomicIncrement`, a very low-level implementation-detail function,
should just receive a pointer.
January 24
On Thursday, 24 January 2019 at 09:49:14 UTC, Manu wrote:
> On Thu, Jan 24, 2019 at 1:25 AM Nicholas Wilson via 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.

True I forgot about that.

> That doesn't address the specific `atomicIncrement` case here, but now
> we're in VERY niche territory; we analysed a lot of cases, and
> concluded that such cases were relatively few, and other choices exist
> to mitigate those cases.
> There are cases that want to do mutation to rvalues (like in pipeline
> functions), and then most cases can use 'out' instead. Remaining cases
> are quite hard to find, and in this particular case, I'd suggest that
> `atomicIncrement`, a very low-level implementation-detail function,
> should just receive a pointer.

Probably.

Oh well, I'll add this to the long list of things to make sure is covered at dconf by the foundation.

January 24
On Thursday, 24 January 2019 at 09:47:46 UTC, Nicholas Wilson wrote:
> Given the simplicity of the fixes for the problems identified I really don't think thats the best way forward. One round of forum review + formal reassessment ought to be enough.
Yes, please! Let not restart the whole dip process for this! The DIP is very lengthy as it currently is, and just encourage the notation of "where good work goes to die" if this have to go through the process all over again.

-Alex

January 24
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. ;)
« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11