Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Friday, 25 January 2019 at 07:02:47 UTC, Walter Bright wrote: On 1/24/2019 4:21 PM, Elie Morisse wrote: I didn't see that coming and I'm deeply frustrated and disappointed by this review and rejection. On the contrary. It is good to find conceptual errors before implementing it. You mean the conceptual errors you made when reviewing it? Like: That the conflation of pass by reference to avoid copying and mutation is not only deliberate but also mitigated by @disable. That the DIP applies to statements, not expressions. That the construction order issue is trivially fixable, by specifying the same behaviour as the non ref case modulo ref.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
No, it is not rejected in principle. Finding serious errors in it on the eve of approval is disappointing, and is not auspicious for being in a hurry to approve it. For example, I spent a lot of time working on ARC, and was all set to move forward with it when Timon stepped in and showed it was fundamentally memory unsafe. I couldn't come up with a reasonable solution. I'm grateful that Timon saved me from much further wasted work and embarrassment. Rvalue references are not a simple problem (although they appear to be). I do believe the problems with it are solvable, but it is a bit unfair to the implementor to dump an incomplete spec on him and have him fill in the gaps. The statement thing is a "do what I meant, not what I wrote" example, and DIPs need to be better than that. You're leaving him to design where the temporaries go, where the gates go, and ensure everything is properly exception safe. I know it's frustrating for you, but it's worse if an rvalue-ref implementation is implemented, shipped, and heralded, and then turns out to be very broken.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/24/2019 12:01 PM, kinke wrote: `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...) The compiler should elide the default-initializations before the call (although it currently does not). The 'out' comes from IDL (Interface Definition Language) and by using out parameters it is directly convertible to/from IDL. Even earlier, 'out' comes from Ada (!) From an efficiency standpoint, having the initialization occur in the function is better than all that duplicated initialization code in all the callers.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/24/2019 4:21 PM, Elie Morisse wrote: I didn't see that coming and I'm deeply frustrated and disappointed by this review and rejection. On the contrary. It is good to find conceptual errors before implementing it. They're a LOT cheaper to fix earlier rather than when it is in the field.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Friday, 25 January 2019 at 00:31:50 UTC, 12345swordy wrote: 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? This will be discussed at DConf at the DLF meeting, which is only 75ish days, along with all other DIPs that are not yet implemented, under review (incl. draft) or recently rejected and a whole host of other topics, so that we can finally get some process direction and vision happening.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thu, Jan 24, 2019 at 6:35 PM Walter Bright via Digitalmars-d-announce wrote: > > 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. "Rush"? We've literally been debating this since my first post on this forum... like, 10 years ago. It's the issue I specifically joined this forum to complain about.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thu, Jan 24, 2019 at 6:35 PM Walter Bright via Digitalmars-d-announce wrote: > > 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. Which issues? The initialization order issue? That's relatively trivial, isolated, and doesn't change the substance of the proposal in any way (unless a working rewrite is impossible, which I'm confident is not the case). The rest of your criticisms certainly did not 'turn up at last minute', they were extensively discussed, and discussion material is available, and present in the community review summary. And then there's the weird expression vs statement comments, which are bizarre, because you literally had to modify my code snippets (removing the semicolons) to read it that way... I can't accept that feedback, that just demonstrates a mis-reading of the DIP. If the DIP could be misunderstood that way, then that's surely revision-worthy, not throw-it-out-and-start-over worthy, and it has nothing to say about the substance of the design.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
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.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
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?
Re: DIP 1016--ref T accepts r-values--Formal Assessment
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.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
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.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
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.)
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thu, Jan 24, 2019 at 3:50 PM Rubn via Digitalmars-d-announce
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.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thu, Jan 24, 2019 at 3:45 PM Walter Bright via Digitalmars-d-announce 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?
Re: DIP 1016--ref T accepts r-values--Formal Assessment
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.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
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.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
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).
Re: DIP 1016--ref T accepts r-values--Formal Assessment
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 Welp, one of the features of the implicit convertion dip that I am going to write depend on this, and it is quite disapointed to see that it is rejected without giving manu a chance for clarification and providing a solution without restarting the dip process again.
Re: Top Five World’s Most Underrated Programming Languages
On Thursday, 24 January 2019 at 14:44:07 UTC, bachmeier wrote: Of course, one could argue that it must have offered enough to keep some of them interested. They were able to get stuff done when they used it. The build in and good performing http server hit the sweet spot. Never underestimate the desire of people to simply get going fast. As a developer, you can be assured that your Go HTTP server will survive a upgrade to a new major release version. That assurance is a bit less with D. ;) One of D its weak spots, that its so general positioned as a C++ replacement, that it lacks a identify for itself.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 24 January 2019 at 21:03:29 UTC, kinke wrote: Describing this stuff in detail (rewritten expression?!), isn't trivial and requires knowledge about how calls and construction/destruction of argument expressions works. E.g., the f() call in the code above is lowered to (-vcg-ast): (bool __gate = false;) , ((A __pfx = a();)) , ((B __pfy = b();)) , __gate = true , f(__pfx, __pfy); Here, (only seemingly unused) temporary `__gate` is used to control the destruction of temporaries with dtors (here just the `__pfx` arg, as `__pfy` is a special case [no potentially throwing later argument expressions...]) at the caller side (false => destruct; true => skip destruction, as it has been moved successfully to the callee, which destructed it). The dtor expressions of these temporaries (e.g., `__gate || __pfx.~this()` for `__pfx`) aren't visible with `-vg-ast`. With this DIP, *all* rvalues passed by ref must be lowered to temporaries. In case they require destruction, the only difference wrt. the by-value case is that they are *always* destructed by the caller (after the call, or if an exception is thrown while they are in scope), i.e., their destruction isn't controlled by `__gate`. Exactly, doing something that could result in a different outcome would be a disaster.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thu, Jan 24, 2019 at 1:05 PM kinke via Digitalmars-d-announce
wrote:
>
> On Thursday, 24 January 2019 at 09:04:41 UTC, Nicholas Wilson
> wrote:
> > On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
> >> 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.
>
> Describing this stuff in detail (rewritten expression?!), isn't
> trivial and requires knowledge about how calls and
> construction/destruction of argument expressions works.
Sure, it's not 'trivial', but it is 'simple' in that it's isolated,
and it only affects the part of the DIP that defines the rewrite
semantic. It doesn't lead to "practically a completely differnet DIP"
as was suggested.
Changing the detail of the rewrite such that it has the proper effect
required by the surrounding text and handles exceptions correctly can
probably be done in such a way that not a single line of text requires
any changes.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thu, Jan 24, 2019 at 12:05 PM kinke via Digitalmars-d-announce 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. Shared in/out functions are very rare by contrast to out parameters. > 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. ;) Maybe... but there are satisfying options for basically any case we could imagine; and worst case, use a pointer rather than ref. Adding stuff like @norval feels heavy-handed, and I personally judge this issue as being severe enough to warrant that baggage. 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?
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 24 January 2019 at 21:57:57 UTC, Rubn wrote:
it could be an error if the function didn't assign the variable
a value instead
I don't like that, conditional mutations like this should work
too:
void conditionalIncrement(bool condition, out long value) {
if (condition)
++value;
}
conditionalIncrement(true, 10); // not allowed, rvalue
long value = 10;
conditionalIncrement(true, out value); // fine
Re: DIP 1016--ref T accepts r-values--Formal Assessment
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.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 24 January 2019 at 09:24:19 UTC, Nicholas Wilson 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? Why isn't it covered by @disable ?
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
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.
Couldn't that just be rewritten as something like
fun(tuple(10).expand);
?
Re: hunt-grpc 0.1.1 released! (Google gRPC for D)
On Thursday, 17 January 2019 at 04:19:27 UTC, Brian wrote: Google gRPC is A high performance, open-source universal RPC framework. [...] Cool. Thanks for contributing. I look forward to using it in a future project with microservices.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 24 January 2019 at 09:04:41 UTC, Nicholas Wilson
wrote:
On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
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.
Describing this stuff in detail (rewritten expression?!), isn't
trivial and requires knowledge about how calls and
construction/destruction of argument expressions works.
E.g., the f() call in the code above is lowered to (-vcg-ast):
(bool __gate = false;) , ((A __pfx = a();)) , ((B __pfy = b();))
, __gate = true , f(__pfx, __pfy);
Here, (only seemingly unused) temporary `__gate` is used to
control the destruction of temporaries with dtors (here just the
`__pfx` arg, as `__pfy` is a special case [no potentially
throwing later argument expressions...]) at the caller side
(false => destruct; true => skip destruction, as it has been
moved successfully to the callee, which destructed it). The dtor
expressions of these temporaries (e.g., `__gate || __pfx.~this()`
for `__pfx`) aren't visible with `-vg-ast`.
With this DIP, *all* rvalues passed by ref must be lowered to
temporaries. In case they require destruction, the only
difference wrt. the by-value case is that they are *always*
destructed by the caller (after the call, or if an exception is
thrown while they are in scope), i.e., their destruction isn't
controlled by `__gate`.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 24 January 2019 at 20:01:45 UTC, kinke wrote: (most args are probably already default-initialized by the callee in the line above the call...) Should be 'by the callER' of course.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
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. ;)
Re: Last Year in D
On Thursday, 24 January 2019 at 13:58:59 UTC, Mike Parker wrote: I said in my annual D Blog retrospective that I wanted to do a similar post focused on D at large. Sebastian Wilzbach sent me a tremendously helpful info dump of all sorts of goings on, most of which I knew nothing about. When I sat down to write the post, it occurred to me that since Adam Ruppe had recently revived 'This Week in D', it would be fun to have him write up a 'Last Year in D'. I asked, he accepted, I sent him Seb's data (thanks Seb!) and the result is now live on the blog. The blog: https://dlang.org/blog/2019/01/24/last-year-in-d/ Reddit: https://www.reddit.com/r/d_language/comments/ajclv0/last_year_in_d_the_d_blog/ I totally aggree, 2018 was such a fantastic year for D. There are a lot of small and big improvements, it is just a pleasure now to use D. Thanks to everyone making this possible!!! Kind regards Andre
Re: DIP 1016--ref T accepts r-values--Formal Assessment
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
Re: Top Five World’s Most Underrated Programming Languages
On Wednesday, 23 January 2019 at 18:42:06 UTC, bauss wrote: Go is garbage and it's only popular because Google is behind it. It has absolutely nothing to do with the language itself. I don't know if I'd agree that it's garbage - it has a lot of appeal to certain types of programmers, though not to me - but I do agree that it's popular (to whatever extent it is) because of Google. I remember when the language was first announced, there were a lot of people excited by the prospect that GOOGLE IS CREATING A LANGUAGE. IT HAS TO BE AWESOME. These were not people who tried the language and found it to be better than the alternatives. They were people who hadn't even seen it. That was back in the days when Microsoft was the devil and Google were the good guys. Of course, one could argue that it must have offered enough to keep some of them interested. They were able to get stuff done when they used it.
Last Year in D
I said in my annual D Blog retrospective that I wanted to do a similar post focused on D at large. Sebastian Wilzbach sent me a tremendously helpful info dump of all sorts of goings on, most of which I knew nothing about. When I sat down to write the post, it occurred to me that since Adam Ruppe had recently revived 'This Week in D', it would be fun to have him write up a 'Last Year in D'. I asked, he accepted, I sent him Seb's data (thanks Seb!) and the result is now live on the blog. The blog: https://dlang.org/blog/2019/01/24/last-year-in-d/ Reddit: https://www.reddit.com/r/d_language/comments/ajclv0/last_year_in_d_the_d_blog/
Re: DIP 1016--ref T accepts r-values--Formal Assessment
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.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thu, Jan 24, 2019 at 1:25 AM Nicholas Wilson via Digitalmars-d-announce 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.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
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 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
Re: DIP 1016--ref T accepts r-values--Formal Assessment
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.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
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?
Re: DIP 1016--ref T accepts r-values--Formal Assessment
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.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
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.
