On 1/30/19 10:05 PM, Manu wrote:
On Wed, Jan 30, 2019 at 6:40 PM Nicholas Wilson via
Digitalmars-d-announce <[email protected]> wrote:
On Wednesday, 30 January 2019 at 18:29:37 UTC, Manu wrote:
On Wed, Jan 30, 2019 at 9:20 AM Neia Neutuladh via
Digitalmars-d-announce <[email protected]>
wrote:
The result of a CastExpression is an rvalue. An implicit cast
is a compiler-inserted CastExpression. Therefore all lvalues
with a potential implicit cast are rvalues.
But there's no existing language rule that attempts to perform
an implicit cast where an lvalue is supplied to a ref arg...?
Why is the cast being attempted? 'p' is an lvalue, and whatever
that does should remain exactly as is (ie, emits a compile
error).
We could perhaps allow this for `const` args, but that feels
like separate follow-up work to me, and substantially lesser
value. This DIP doesn't want to change anything about lvalues.
It appears to say it does:
fun(my_short); // implicit type conversions (ie, short->int
promotion)
You should clarify that ;)
Yes, as said above, read `short(10)`. I can understand the confusion
that it may look like a variable when taken out of context; but listed
beneath the heading immediately above which says:
"This inconvenience extends broadly to every manner of **rvalue**
passed to functions"
It didn't occur to me the reader might interpret the clearly stated
list of cases of rvalues passed to functions to include arguments that
are not rvalues.
The name was just chosen to indicate the argument is a short, perhaps
an enum, or any expression that is a short... I could have used
`short(10)`, but apparently I didn't think of it at the time.
Is this the basis for the claims of "a hole you could drive a truck
through"?
Affirmative.
With the restriction that the expression passed into the function must
be an rvalue to start with, by Walter's and my understanding, the
proposed semantics would work and be helpful.
Again, a request for clarification, and a
couldn't-possibly-be-more-trivial revision may resolve this.
Negative.
It must be clear that the reason of this misunderstanding is squarely
due to the DIP itself. It has multiple problems of informality and vague
language that have worked together to cause said misunderstanding. (It
is great it's just that, a misunderstanding; I have been worried people
would believe such an awful semantics was considered just fine. That
explains but does not justify my use of unkind language.)
The DIP must convince the reader, and in a way the reader does not "owe"
the DIP. For good reason, they call the research theme chosen by a
doctoral candidate a "charge"; the root of "dissertation" is Latin for
"debate"; and the final doctoral examination is plainly called a
"defense". The whole thing is structured like a criminal investigation
:o). Of course we don't want to be as harsh as academics could get, but
we don't want to transform DIP acceptance into a farmers market
bargaining process.
So the code with my_short was open to interpretation. Cool. In a
thorough submission, however, there would have been many places that
clear that up:
* Use of a distinct notation (non-code non-text font for metalanguage,
i.e. general expressions);
* Description of the typechecking process, with examples of code that
passes and code that fails;
* A clarification that lowering proceeds not against all expressions,
but only against rvalues;
* Several places in text in which it is explained that rvalues resulted
from implicit conversions are not eligible;
* etc. etc. etc.
So if we rejected the DIP, we didn't do so on account of one word that
can be so easily changed; we did so on account of a DIP that as a whole
failed to clarify what it purports to do (and equally importantly, to
not do).
The purpose of us all is to move things forward, and in that spirit
allow me to put forward a short list of matters that a revised proposal
should do, at a minimum:
* Walter has posted about a few issues with various parts of the
proposal. Those should be addressed.
* The "Reference" section does good to mention the issues, but the
litany of forum discussions has no value besides "there have been
repeated discussion in community forums of the topic", and refer to a
list in an bibliography. Placing them in the "Reference" section
suggests the reader that they need to read the forum debates in order to
understand the DIP, which isn't and shouldn't be the case.
* An "Existing Work" section discussing C++ (and possibly Rust) is a
must. Studious neglect of what other languages do and what problems they
have does not serve us well. I think Walter could help with that.
* The "Rationale" section currently focuses only on issues caused by the
current rule. It should have three parts:
- Open with a brief description of the current rule and why it is that
way. Here we have the advantage that confusing conversions are disallowed.
- Then continue with "However, the binding rule also causes a variety of
undue limitations whereby valid and useful code is rejected". Insert
examples.
- Then continue with "If the rule got relaxed so as to only allow
certain bindings but not all, we could allow the sensible cases
illustrated above, yet still disallow the problematic cases."
Boom! The reader is already loving it.
* Subsection "Why are we here?" is not necessary. Its first part is
folded in the "Rationale", and its second part is actually clearly an
argument that is part of the rationale. IMHO the "pipeline" argument is
not necessary, or can be moved in an "Examples of use" section toward
the end.
* "Description" needs a complete rewrite. Here typing rules, lowering,
exception safety, should be explained in ultimate detail using
metalanguage (not just a few simplistic examples). It should be
mechanically clear how an arbitrary expression containing function calls
can be lowered into preexisting D code. Again I very much recommend
lowering expressions to expressions instead of statements to statements,
but anything clear and thorough will do.
* Also the description should clarify what happens in certain odd cases,
such as alias this, class inheritance, properties that return lvalues
vs. rvalues using the same syntax, and probably more. An important
aspect of the proposal is "rvalues look different than lvalues, so the
user won't get confused".
* "Temporary destruction" is unnecessary.
* "Function calls as arguments" us unnecessary if "Description"
describes the feature completely.
* "Interaction with return ref" is probably unnecessary as a subsection
but it would be nice to have as an explanatory example after the general
lowering has been introduced.
* "Overload resolution" - see Walter's comments.
* Eliminate imprecise language "It has been noted that..." (by whom?
when? reference?) If no reference, fine - spend a sentence to create
that note!
* "Why not XXX?" should be massaged into a "Workarounds" section that
follows the "Rationale" section, or is a subsection of it.
* "Key use cases" is good, and more examples should be only better.
Hope this helps! The outlook is definitely better after this
misunderstanding has been cleared.
Andrei
