January 24
On Thursday, 24 January 2019 at 22:38:01 UTC, Manu wrote:
> Shared in/out functions are very rare by contrast to out parameters.

The code I write is the exact opposite of your perception - some occasional side-effect-mutations of params, and almost no stuff 'returned' as out params.

> What are some legit cases where, assuming a world where we want to avoid naked ref in cases where we want to receive compile errors when users pass rvalues, aren't satisfied by other options?

Proposed `out` semantics:
---
void increment(out long value) { ++value; }
increment(out value);
---

vs. pointer version with current `out` semantics:
---
void increment(long* pValue) { ++(*pValue); }
increment(&value);
---

The pointer workaround is both ugly (C) and unsafe (you can pass null).
January 24
On 1/24/2019 1:31 AM, Manu wrote:
> 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.

It's no problem if you want to rework the existing text, just submit it as a new DIP.
January 24
On Thursday, 24 January 2019 at 23:18:11 UTC, kinke wrote:
> Proposed `out` semantics:
> ---
> void increment(out long value) { ++value; }
> increment(out value);
> ---
>
> vs. pointer version with current `out` semantics:
> ---
> void increment(long* pValue) { ++(*pValue); }
> increment(&value);
> ---
>
> The pointer workaround is both ugly (C) and unsafe (you can pass null).

@safe void safestFunction() {
    int* ptr;
    increment(out *ptr); // can also pass null to ref/out even in @safe
}

It's probably going to be a hard sell to change the behavior of out now as well. It'd break quite a bit of code I think, did a search through druntime and phobos and quite a few functions use it. Maybe user code uses it less, I know I never use it.
January 24
On Thu, Jan 24, 2019 at 3:45 PM Walter Bright via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On 1/24/2019 1:31 AM, Manu wrote:
> > 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.
>
> It's no problem if you want to rework the existing text, just submit it as a new DIP.

This process has a long and deep pipe, why should it be a new DIP?
There's nothing from the rejection text that would motivate me to
change any words... Is it that you reject it 'in principle'? If so,
there's nothing I can ever do about that.
This took a substantial amount of my life, and you could have sought
clarification, or a revision before a rejection.
The rejection appears to be premised by misunderstanding more than
anything, and a one very real (but isolated) technical issue that I
believe can be corrected readily enough without affecting the
surrounding text.

The only improvement I could make is to better fold the discussion from the community review into the core text, but it's not like that digest wasn't already right there during consideration.

I have no idea how you guys managed to edit and re-frame my DIP as applying to expressions? You removed the semicolons from the statements, and then told me I had no idea what I was doing, mixing expressions with statements that way... why did you do that?
January 24
On Thu, Jan 24, 2019 at 3:50 PM Rubn via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On Thursday, 24 January 2019 at 23:18:11 UTC, kinke wrote:
> > Proposed `out` semantics:
> > ---
> > void increment(out long value) { ++value; }
> > increment(out value);
> > ---
> >
> > vs. pointer version with current `out` semantics:
> > ---
> > void increment(long* pValue) { ++(*pValue); }
> > increment(&value);
> > ---
> >
> > The pointer workaround is both ugly (C) and unsafe (you can
> > pass null).
>
> @safe void safestFunction() {
>      int* ptr;
>      increment(out *ptr); // can also pass null to ref/out even in
> @safe
> }
>
> It's probably going to be a hard sell to change the behavior of out now as well. It'd break quite a bit of code I think, did a search through druntime and phobos and quite a few functions use it. Maybe user code uses it less, I know I never use it.

I think any issues with `out` are tangential though. `out` does 'work'
right now, and it's a valid way to address the concern with respect to
one broad use case for ref.
Theoretically, `out` is the right solution for that particular class
of calling contexts, and any further issued with `out` should be taken
as a separate issue/discussion.
January 24
On 1/24/2019 1:03 PM, kinke wrote:
> (bool __gate = false;) , ((A __pfx = a();)) , ((B __pfy = b();)) , __gate = true , f(__pfx, __pfy);

There must be an individual gate for each of __pfx and pfy. With the rewrite above, if b() throws then _pfx won't be destructed.

(All this rigamarole is part of why exception handling isn't free, even in the happy case.)
January 25
On Thursday, 24 January 2019 at 23:59:30 UTC, Walter Bright wrote:
> On 1/24/2019 1:03 PM, kinke wrote:
>> (bool __gate = false;) , ((A __pfx = a();)) , ((B __pfy = b();)) , __gate = true , f(__pfx, __pfy);
>
> There must be an individual gate for each of __pfx and pfy. With the rewrite above, if b() throws then _pfx won't be destructed.
>
> (All this rigamarole is part of why exception handling isn't free, even in the happy case.)

Indeed, and thats why it should be have exactly the same as if there were no `ref` involved, except for the not copying stuff. Behaving and differently is, a) wrong and, b) going to cause a lot of confusion.
January 25
On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
> https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md

> Here, the DIP Author clearly expresses two reasons why a programmer may choose to declare a function to accept ref arguments. The Language Maintainers see this as the core of the proposal and would expect the distinction between the two cases to be maintained throughout. However, this proposal does not maintain the distinction and instead conflates the two cases. 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.

Sorry, but that's just irrelevant / missing the point.

On Thursday, 24 January 2019 at 09:31:41 UTC, Manu wrote:
> Hooray!
> Who didn't see that coming 10 years off!

I didn't see that coming and I'm deeply frustrated and disappointed by this review and rejection.
January 25
On Thursday, 24 January 2019 at 23:43:21 UTC, Walter Bright wrote:
> It's no problem if you want to rework the existing text, just submit it as a new DIP.

And wait for another 180+ days for a fix? Come on dude, can you understand the frustration being display here?
January 24
On 1/24/2019 4:31 PM, 12345swordy wrote:
> And wait for another 180+ days for a fix? Come on dude, can you understand the frustration being display here?

Of course it's frustrating. On the other hand, we've had a lot of problems stemming from implementing features without thoroughly understanding them.

Rvalue references have a lot of subtleties to them, and we should not rush into it, especially since these issues only turned up at the last minute.
1 2 3 4 5 6 7 8 9 10 11 12 13