Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/30/19 10:12 PM, Manu wrote:
On Wed, Jan 30, 2019 at 7:05 PM Nicholas Wilson via
Digitalmars-d-announce wrote:
On Thursday, 31 January 2019 at 02:10:05 UTC, Manu wrote:
On Wed, Jan 30, 2019 at 1:05 PM Andrei Alexandrescu via
fun(my_short); // implicit type conversions (ie, short->int
promotion)
Oh I see.
fun(short(10)); // implicit type conversions (ie, short->int
promotion)
I did not intend for this DIP to apply to anything other than
rvalues.
I can totally see how that's not clear. `my_short` should be an
rvalue
of some form, like the rest.
Is that the only such line?
I think so.
Presumably my_short is a variable of type short. Is that
correct?
It is not. It should be an rvalue like everything else. Perhaps
it's an enum... but I should write `short(10)`, that would be
clear.
It would.
* DIP 1016 proposes a hole in the language one could drive a
truck through.
I still can't see a truck-sized hole.
* The problem goes undetected in community review.
I don't know how I could have influenced this outcome.
* Its own author seems to not have an understanding of what
the DIP proposes.
More classy comments. I can't get enough of the way you
belittle people.
I made a 1-word error, where I should have written `short(10)`
to be clear.
1-word error feels amendment-worthy, and not a call for "let's
start
over from scratch".
You should just PR it back to review
I can't do that, it's been rejected, with mostly incorrect rejection
text affixed to the bottom.
with that fix and a note
about how it lowers to statements (incl. an example of
lambdification for if/while/for/switch statements (see
https://forum.dlang.org/post/qysmnatmjquuhylaq...@forum.dlang.org
))
I'm pretty sure that's not necessary. I haven't understood why this
noise about expressions. This DIP applies to statements.
I can't see how there's any problem with the lowering if the statement
is a control statement?
if (ref_fun(10)) { ... }
==>
{
int __tmp = 10;
if (ref_fun(__tmp)) { ... }
}
What's the trouble?
The trouble is major.
Replace "if" with "while":
while (ref_fun(10)) { ... }
==>
{
int __tmp = 10;
while (ref_fun(__tmp)) { ... }
}
That means ref_fun is called with the same lvalue multiple times. In all
likelihood this is not what you want!
A possible retort is: "Of course, while would not be lowered that way,
but a slightly different way!" etc. The point is, ALL OF THAT must be in
the DIP, not assumed obvious or clarified in informal discusson outside
the DIP.
Again: please be thorough, state your assumptions, cover all cases.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/30/19 10:05 PM, Manu wrote: On Wed, Jan 30, 2019 at 6:40 PM Nicholas Wilson via Digitalmars-d-announce 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 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
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/30/19 9:10 PM, Manu wrote: * Its own author seems to not have an understanding of what the DIP proposes. More classy comments. I can't get enough of the way you belittle people. You're right. I have deleted this post a few seconds after having sent it on account of that remark, but somehow it got resuscitated. Please accept my apologies.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Wed, Jan 30, 2019 at 7:35 PM Steven Schveighoffer via Digitalmars-d-announce wrote: > > On 1/30/19 10:05 PM, Manu wrote: > > On Wed, Jan 30, 2019 at 6:40 PM Nicholas Wilson via > > Digitalmars-d-announce wrote: > >> 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"? Again, a request for clarification, and a > > couldn't-possibly-be-more-trivial revision may resolve this. > > > > I think changing it to `short(10)` helps the argument that you didn't > intend it to mean conversions from lvalues, but I'd recommend still > spelling out that they are forbidden. I mean, the heading of the DIP is "ref T accepts r-values", the whole abstract talks about nothing but rvalues, the header of the confusing block couldn't say 'rvalues' more clearly... I didn't consider that it was possible to confuse this as anything other than an rvalue DIP... but yes, I can certainly spell it out. > Leaving the reader to infer intent is not as good as clarifying intent > directly. The whole rvalue vs. lvalue thing is confusing to me, because > I assumed an lvalue converted to a different type changes it to an > rvalue. I think of it like an implicit function that returns that new value. Obviously all of this is true, but I didn't think of it that way; didn't realise there was a point of confusion, and nobody during the community reviews appeared to raise confusion either. I'll obviously revise it, except that it's rejected and moved to the rejected folder. For reference, the key point that justifies its mention in the first place is a little further down: "It is important that T be defined as the parameter type, and not auto (ie, the argument type), because it will allow implicit conversions to occur naturally, with identical behavior as when the parameter is not ref." It was important to consider mis-matching types (implicit conversions), because there is detail in the rules that allows them to work properly and make the call uniform with the same function if it passed by-val.
Re: DConf 2019 Early-Bird Registration Now Open
On Wednesday, 30 January 2019 at 20:12:49 UTC, Jacob Carlborg wrote: Has a hotel for post-conference gathering* been picked? Not yet. I'll update the venue page as soon as we get something worked out. https://dconf.org/2019/venue.html * We all know this actually means Beer Conf :D There's a chance we could wind up with a pub as the gathering spot :-)
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/30/19 10:05 PM, Manu wrote: On Wed, Jan 30, 2019 at 6:40 PM Nicholas Wilson via Digitalmars-d-announce wrote: 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"? Again, a request for clarification, and a couldn't-possibly-be-more-trivial revision may resolve this. I think changing it to `short(10)` helps the argument that you didn't intend it to mean conversions from lvalues, but I'd recommend still spelling out that they are forbidden. Leaving the reader to infer intent is not as good as clarifying intent directly. The whole rvalue vs. lvalue thing is confusing to me, because I assumed an lvalue converted to a different type changes it to an rvalue. I think of it like an implicit function that returns that new value. -Steve
Re: DIP 1016 should use expression lowering, not statement lowering
On 1/30/19 10:03 PM, Nicholas Wilson wrote:
On Thursday, 31 January 2019 at 02:29:47 UTC, Steven Schveighoffer wrote:
I came up with this idea based on tempCString, but it doesn't work:
So I don't get why it doesn't work. But if that was fixed, could be a
potential workaround without requiring a DIP.
Thats nice! But it doesn't fix the problem that in generic code you
don't know without checking if you need to do that. Also the template
bloat.
Yeah, it could do this too:
auto ref rv(T)(auto ref T t)
{
static if(__traits(isRef, t)) return t;
else /* do the other stuff */
}
But yes, template bloat. Plus having to put rv on everything... would
suck. The DIP to me seems like it should be good with the clarification
of not applying to lvalue -> rvalue auto translations.
-Steve
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Wed, Jan 30, 2019 at 7:05 PM Nicholas Wilson via
Digitalmars-d-announce wrote:
>
> On Thursday, 31 January 2019 at 02:10:05 UTC, Manu wrote:
> > On Wed, Jan 30, 2019 at 1:05 PM Andrei Alexandrescu via
> >> fun(my_short); // implicit type conversions (ie, short->int
> >> promotion)
> >>
> >
> > Oh I see.
> >
> >> fun(short(10)); // implicit type conversions (ie, short->int
> >> promotion)
> >
> > I did not intend for this DIP to apply to anything other than
> > rvalues.
> > I can totally see how that's not clear. `my_short` should be an
> > rvalue
> > of some form, like the rest.
> > Is that the only such line?
>
> I think so.
>
> >> Presumably my_short is a variable of type short. Is that
> >> correct?
> >
> > It is not. It should be an rvalue like everything else. Perhaps
> > it's an enum... but I should write `short(10)`, that would be
> > clear.
>
> It would.
>
> >> * DIP 1016 proposes a hole in the language one could drive a
> >> truck through.
> >
> > I still can't see a truck-sized hole.
> >
> >> * The problem goes undetected in community review.
> >
> > I don't know how I could have influenced this outcome.
> >
> >> * Its own author seems to not have an understanding of what
> >> the DIP proposes.
> >
> > More classy comments. I can't get enough of the way you
> > belittle people.
> >
> > I made a 1-word error, where I should have written `short(10)`
> > to be clear.
> > 1-word error feels amendment-worthy, and not a call for "let's
> > start
> > over from scratch".
>
> You should just PR it back to review
I can't do that, it's been rejected, with mostly incorrect rejection
text affixed to the bottom.
> with that fix and a note
> about how it lowers to statements (incl. an example of
> lambdification for if/while/for/switch statements (see
> https://forum.dlang.org/post/qysmnatmjquuhylaq...@forum.dlang.org
> ))
I'm pretty sure that's not necessary. I haven't understood why this
noise about expressions. This DIP applies to statements.
I can't see how there's any problem with the lowering if the statement
is a control statement?
if (ref_fun(10)) { ... }
==>
{
int __tmp = 10;
if (ref_fun(__tmp)) { ... }
}
What's the trouble?
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Wed, Jan 30, 2019 at 6:40 PM Nicholas Wilson via Digitalmars-d-announce 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 > > 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"? Again, a request for clarification, and a couldn't-possibly-be-more-trivial revision may resolve this.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 31 January 2019 at 02:10:05 UTC, Manu wrote: On Wed, Jan 30, 2019 at 1:05 PM Andrei Alexandrescu via fun(my_short); // implicit type conversions (ie, short->int promotion) Oh I see. fun(short(10)); // implicit type conversions (ie, short->int promotion) I did not intend for this DIP to apply to anything other than rvalues. I can totally see how that's not clear. `my_short` should be an rvalue of some form, like the rest. Is that the only such line? I think so. Presumably my_short is a variable of type short. Is that correct? It is not. It should be an rvalue like everything else. Perhaps it's an enum... but I should write `short(10)`, that would be clear. It would. * DIP 1016 proposes a hole in the language one could drive a truck through. I still can't see a truck-sized hole. * The problem goes undetected in community review. I don't know how I could have influenced this outcome. * Its own author seems to not have an understanding of what the DIP proposes. More classy comments. I can't get enough of the way you belittle people. I made a 1-word error, where I should have written `short(10)` to be clear. 1-word error feels amendment-worthy, and not a call for "let's start over from scratch". You should just PR it back to review with that fix and a note about how it lowers to statements (incl. an example of lambdification for if/while/for/switch statements (see https://forum.dlang.org/post/qysmnatmjquuhylaq...@forum.dlang.org ))
Re: DIP 1016 should use expression lowering, not statement lowering
On Thursday, 31 January 2019 at 02:29:47 UTC, Steven Schveighoffer wrote: I came up with this idea based on tempCString, but it doesn't work: So I don't get why it doesn't work. But if that was fixed, could be a potential workaround without requiring a DIP. Thats nice! But it doesn't fix the problem that in generic code you don't know without checking if you need to do that. Also the template bloat.
Re: DIP 1016 should use expression lowering, not statement lowering
On 1/29/19 6:52 AM, Andrei Alexandrescu wrote:
While writing this example:
int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
if (alloc.reallocate(a, 200 * int.sizeof))
{
assert(a.length == 200);
}
=>
int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
void[] __temp0 = a;
if (alloc.reallocate(__temp0, 200 * int.sizeof)
{
assert(a.length == 200);
}
I noticed a problem - the lowering as informally described in DIP 1016
makes it difficult to figure how function calls present in control
statements like if, while, etc. should behave. Where should the
temporary go? An expression-based lowering clarifies everything. A
statement-based lowering would need to work on a case basis for all
statements involving expressions.
I don't think it's very difficult or confusing. Any rvalue in any
expression that requires ref should be implicitly declared before the
statement that contains the expression, and include a new scope:
>
{
auto _tmpr1 = r1;
auto _tmpr2 = r2;
auto _tmpr3 = r3;
...
auto _tmprN = rN;
}
Essentially, nothing is different from existing semantics today, when
rvalues are used and provides reference semantics (yes, it's possible,
see tempCString). They live until the end of the statement. It's how
this has to be. It can't be expression based.
-Steve
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Wed, Jan 30, 2019 at 12:40 PM 12345swordy via
Digitalmars-d-announce 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
> > wrote:
> >>
> >> On Wed, 30 Jan 2019 09:15:36 -0800, Manu wrote:
> >> > Why are you so stuck on this case? The DIP is about
> >> > accepting rvalues,
> >> > not lvalues...
> >> > Calling with 'p', an lvalue, is not subject to this DIP.
> >>
> >> 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?
> Because of the rewrite that your proposed in your dip.
>
> void fun(ref int x);
>
> fun(10);
>
> {
>T __temp0 = void;
>fun(__temp0 := 10);
> }
>
> lets replace 10 with a short variable named: S
"a short variable named: S" is an lvalue, so why would the rewrite be
attempted? S must be an rvalue for any rewrite to occur. We're talking
about rvalues here.
Re: DIP 1017--Add Bottom Type--Formal Assessment
On Wednesday, 30 January 2019 at 20:50:42 UTC, Johannes Loher wrote: Am 30.01.19 um 15:05 schrieb Mike Parker: Given the nature of the feedback in both review rounds this DIP has gone through, Walter has decided to reject his own DIP. He still believes there is a benefit to adding a bottom type to the language, but this proposal is not the way to go about it. He hopes to revisit the issue in the future. Thanks to everyone who provided feedback. I believe this is a good decision and the proper way forward. I also think that there is indeed a benefit in adding a bootom type to the language so I'd be happy to help with a new attempt as much my limited knowledge of type theory permits. +1 Well done Walter, for the professionalism in handling the decision, and for the bravery in trying to push something he believe useful for the language, also if he is not as competent as Timon in this field. Kudos to you, for the example given, and for the temperance! -- P
Re: GtkD Blog Now Up and Running
On Friday, 25 January 2019 at 21:16:59 UTC, Ron Tarrant wrote: Hi y'all, As of January 11, 2019, http://gtkdcoding.com is up. It's a blog, it's a github page, it's simple examples of how to use GtkD for all that GUI stuff. My approach is to lay out a firm foundation for both imperative and object-oriented paradigms, then build from there, taking things one step at a time. This being Friday, the 4th post went up this morning. Please do let me know if you find it useful. And why did I wait until now to announce? Well, on day one, it seemed a bit silly to announce with only one post. After the second and third, well... I still didn't feel there was enough to warrant excitement. But four posts? Now that's something to speak up about, ain't it? Yup. That's what I thought, too. Some simple screenshots would be nice to see -- but good job on this. Nice to see examples/how-to's. Hope you keep going into complex topics.
Re: GtkD Blog Now Up and Running
On 30-01-2019 21:07, Jacob Carlborg wrote: On 2019-01-30 11:35, Ron Tarrant wrote: You said you're on OSX, right? Is it possible that dub just isn't as cooperative on Windows 10? Of course, if you can see something in this output that hints at a fix, please let me know. It's Optlink being stupid as always. If you want to figure out what's wrong you can invoke Dub with the "--verbose" flag to have it print the commands it's running, i.e. how it's invoking the compiler and the linker. You can do the same thing when invoking the compiler manually by adding "-v" to see how it links the application and compare that with Dub. Or, you can try compiling as COFF instead of OMF which will not use Optlink. Add the flag "--arch=x86mscoff" when invoking Dub. This is whats going on: https://issues.dlang.org/show_bug.cgi?id=15418 To work around this you can either build things with "--arch=x86mscoff" or tell dub not to build the debug version with "--build=plain". -- Mike Wey
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Monday, 28 January 2019 at 19:58:24 UTC, Andrei Alexandrescu
wrote:
On 1/28/19 1:00 PM, Andrei Alexandrescu wrote:
It seems to me that a proposal adding the "@rvalue" attribute
in function signatures to each parameter that would accept
either an rvalue or an lvalue would be easy to argue.
- No exposing existing APIs to wrong uses
- The function's writer makes the decision ("I'm fine with
this function taking an rvalue")
- Appears in the function's documentation
- Syntax is light and localized where it belongs
- Scales well with number of parameters
- Transparent to callers
The inverse, the @norval attribute, would feature all but the
first advantages, at least once people get used to normal ref
allowing (some) rvalues too. I can't think of many good reasons
for a callee to disallow rvalues (with matching type at least);
your example wrt. interlockedIncrement() is a good one, as
synchronization overhead clearly isn't required for an rvalue.
But my usages of (mutable) ref are >99% of the time something
like:
Header readHeader(ref Stream stream)
{
// read from & advance stream, return parsed header
}
where I'd like to be able put everything into one line if trivial
(stream not required later on):
readHeader(Stream("file")).doSomething();
(And const ref is mostly used for performance with bigger
structs, where rvalues are absolutely fine).
TLDR: I'd guess that I'd need to type `@rvalue` about 1000 times
as often as `@norval`. I'm not kidding.
TL;DR: it could be argued that the only dangerous conversions
are lvalue -> temp rvalue -> ref, so only disable those. The
conversion rvalue -> temp rvalue -> ref is not dangerous
because the starting value on the caller side could not be
inspected after the call anyway.
I agree that the DIP needs to be clearer wrt. rvalues resulting
from implicit conversions. I also agree with the above point. I'm
just not sure we need to allow implicit conversions from rvalue
argument expressions at all. To minimize the changes for overload
resolution, it might be enough to allow rvalue argument
expressions of matching type only, i.e., the types which are
allowed for current ref semantics. After all, I don't plan to use
the proposed ref semantics for primitive types where that might
come in handy (something silly like `modf(x, 123.456)` if the
second param is a `ref real`), and explicit casts would IMO be an
acceptable price to pay for safety and visibility in the
remaining cases.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/30/19 1:29 PM, Manu wrote:
On Wed, Jan 30, 2019 at 9:20 AM Neia Neutuladh via
Digitalmars-d-announce wrote:
On Wed, 30 Jan 2019 09:15:36 -0800, Manu wrote:
Why are you so stuck on this case? The DIP is about accepting rvalues,
not lvalues...
Calling with 'p', an lvalue, is not subject to this DIP.
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...?
That's exactly what lowerings are for: to precisely specify what should
happen when the proposed construct is used. DIP 1016 proposes a lowering
of the form:
{
T __temp0 = expr;
fun(__temp0);
}
In the first step, an implicit conversion of an lvalue may take place.
Why is the cast being attempted? 'p' is an lvalue, and whatever that
does should remain exactly as is (ie, emits a compile error).
Not according to DIP 1016. Here is an example pasted from it:
This inconvenience extends broadly to every manner of rvalue passed to
functions, including:
...
fun(my_short); // implicit type conversions (ie, short->int promotion)
Presumably my_short is a variable of type short. Is that correct?
Again (this is not a rhetorical or sarcastic question): are you sure DIP
1016 expresses what you are trying to accomplish?
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.
What we have here is:
* DIP 1016 proposes a hole in the language one could drive a truck through.
* The problem goes undetected in community review.
* Its own author seems to not have an understanding of what the DIP
proposes.
Andrei
Re: DIP 1017--Add Bottom Type--Formal Assessment
Am 30.01.19 um 15:05 schrieb Mike Parker: > Given the nature of the feedback in both review rounds this DIP has gone > through, Walter has decided to reject his own DIP. He still believes > there is a benefit to adding a bottom type to the language, but this > proposal is not the way to go about it. He hopes to revisit the issue in > the future. > > Thanks to everyone who provided feedback. I believe this is a good decision and the proper way forward. I also think that there is indeed a benefit in adding a bootom type to the language so I'd be happy to help with a new attempt as much my limited knowledge of type theroy permits.
Re: 5 reasons the D programming language is a great choice for development
On Wednesday, 30 January 2019 at 20:46:07 UTC, H. S. Teoh wrote: On Wed, Jan 30, 2019 at 08:34:58PM +, Simen Kjærås via Digitalmars-d-announce wrote: I found this article espousing D's strengths today: https://opensource.com/article/17/5/d-open-source-software-development It appears to be written by our very own `aberba`, who also frequently participates in these forums. Good read! T I'm positive I've seen it posted before
Re: 5 reasons the D programming language is a great choice for development
On Wed, Jan 30, 2019 at 08:34:58PM +, Simen Kjærås via Digitalmars-d-announce wrote: > I found this article espousing D's strengths today: > https://opensource.com/article/17/5/d-open-source-software-development It appears to be written by our very own `aberba`, who also frequently participates in these forums. Good read! T -- Give a man a fish, and he eats once. Teach a man to fish, and he will sit forever.
Re: DIP 1016 should use expression lowering, not statement lowering
On 1/30/19 3:34 AM, Kagamin wrote: On Tuesday, 29 January 2019 at 11:52:40 UTC, Andrei Alexandrescu wrote: Where should the temporary go? Doesn't D already specify allocation and lifetime of temporaries? AIU the DIP doesn't invent the notion of a temporary. My bad, I overloaded the term "temporary". I meant the variable inserted by the lowering.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
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
wrote:
On Wed, 30 Jan 2019 09:15:36 -0800, Manu wrote:
> Why are you so stuck on this case? The DIP is about
> accepting rvalues,
> not lvalues...
> Calling with 'p', an lvalue, is not subject to this DIP.
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?
Because of the rewrite that your proposed in your dip.
void fun(ref int x);
fun(10);
{
T __temp0 = void;
fun(__temp0 := 10);
}
lets replace 10 with a short variable named: S
void fun(ref int x);
fun(S)
{
T __temp0 = void;
fun(__temp0 := S);
}
fun(__temp0 := S) This is where the cast is being attempted. As
__temp0 is aninteger type and S is a
short type
5 reasons the D programming language is a great choice for development
I found this article espousing D's strengths today: https://opensource.com/article/17/5/d-open-source-software-development
Re: DConf 2019 Early-Bird Registration Now Open
On 2019-01-28 15:07, Mike Parker wrote: I've published a post on the blog with updates about DConf 2019 registrations, the invited keynote speaker, the Symmetry Autumn of Code finalist, and the previously announced fundraiser for a new forum server. Early-bird registrations are $340 again this year and will remain available until March 17, 24:00 AOE. This time around, we have to factor in a 20% VAT for all registrations, so the actual price will be $408. Has a hotel for post-conference gathering* been picked? * We all know this actually means Beer Conf :D -- /Jacob Carlborg
Re: GtkD Blog Now Up and Running
On 2019-01-30 11:35, Ron Tarrant wrote: You said you're on OSX, right? Is it possible that dub just isn't as cooperative on Windows 10? Of course, if you can see something in this output that hints at a fix, please let me know. It's Optlink being stupid as always. If you want to figure out what's wrong you can invoke Dub with the "--verbose" flag to have it print the commands it's running, i.e. how it's invoking the compiler and the linker. You can do the same thing when invoking the compiler manually by adding "-v" to see how it links the application and compare that with Dub. Or, you can try compiling as COFF instead of OMF which will not use Optlink. Add the flag "--arch=x86mscoff" when invoking Dub. -- /Jacob Carlborg
Re: GtkD Blog Now Up and Running
On 2019-01-30 03:00, Neia Neutuladh wrote: Might I recommend instead: dependency "gtk-d" version="3.8.5" This depends on gtk-d 3.8.5 and only that version. If there is a breaking change in 3.8.6 despite semantic versioning, your code keeps working. In libraries, I prefer using ~> to give more freedom to people depending on my code. But in applications, that isn't a concern. May as well only allow the code to be built with the versions of your dependencies that you've actually tested. That's what the dub.selections.json file is for. It will lock down the version of all dependencies, direct and indirect dependencies. For applications the dub.selections.json should be under version control, while for libraries it should be ignored. -- /Jacob Carlborg
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Wednesday, 30 January 2019 at 16:47:48 UTC, Don wrote: On Wednesday, 30 January 2019 at 13:58:38 UTC, 12345swordy wrote: I do not accept gut feeling as a valid objection here. The current workarounds is shown to be painful as shown in the dip and in the discussions that it currently link. That *the* motivation here. Like I said previously I am on the reviews side and that's it. In terms of what exactly? Walter had stated they do not rejected the dip in principle. You apparently *do* rejected it in principle, from judging your posts here. By the way I don't like your tone when you say: "I do not accept gut feeling as a valid objection here". If you stated that you think it a bad/good idea without explaining why you think it. That is what I call "gut feeling" Alright we're talking about a change that have been on hold for almost 10 years, if it was simple it would already been done. The current dip system didn't exist 10 years prior. I wouldn't say that things are already done due to them being simple, as there are quite number of "simple" features that wasn't implemented already (Looking at you tuples). -Alex
Re: GtkD Blog Now Up and Running
On Wednesday, 30 January 2019 at 09:48:14 UTC, Ron Tarrant wrote: On Saturday, 26 January 2019 at 16:53:18 UTC, Antonio Corbi wrote: [1] https://sites.google.com/site/gtkdtutorial/ [2] http://britseyeview.com/software/articles/gsgtkd.html [3] https://gitlab.com/csoriano/GtkDApp Took a look this morning. I'd come across the Brit's Eye View articles, but not the others. As I'm about to write something on menus, these will definitely come in handy. Thanks, Antonio. You are welcome, :) Antonio
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Wed, Jan 30, 2019 at 9:20 AM Neia Neutuladh via Digitalmars-d-announce wrote: > > On Wed, 30 Jan 2019 09:15:36 -0800, Manu wrote: > > Why are you so stuck on this case? The DIP is about accepting rvalues, > > not lvalues... > > Calling with 'p', an lvalue, is not subject to this DIP. > > 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.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Tue., 29 Jan. 2019, 10:25 pm Walter Bright via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com wrote:
> On 1/29/2019 3:45 AM, Andrei Alexandrescu wrote:
> > I am talking about this:
> >
> > int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
> > if (alloc.reallocate(a, 200 * int.sizeof)
> > {
> > assert(a.length == 200);
> > }
>
> Even simpler:
>
>void func(ref void* p) {
> free(p); // frees (1)
> p = malloc(100); // (2)
>}
>
>int* p = cast(int*)malloc(16); // (1)
>func(p);// p copied to temp for conversion to
> void*
>free(p);// frees (1) again
>// (2) is left dangling
>
> It's a memory corruption issue, with no way to detect it.
>
Why are you so stuck on this case? The DIP is about accepting rvalues, not
lvalues...
Calling with 'p', an lvalue, is not subject to this DIP.
>
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Wed, 30 Jan 2019 09:15:36 -0800, Manu wrote: > Why are you so stuck on this case? The DIP is about accepting rvalues, > not lvalues... > Calling with 'p', an lvalue, is not subject to this DIP. 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.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Wednesday, 30 January 2019 at 13:58:38 UTC, 12345swordy wrote: I do not accept gut feeling as a valid objection here. The current workarounds is shown to be painful as shown in the dip and in the discussions that it currently link. That *the* motivation here. Like I said previously I am on the reviews side and that's it. By the way I don't like your tone when you say: "I do not accept gut feeling as a valid objection here". I don't think you would like if I say that your opinion is biased because you know the author either, so don't go that way, because it's not only me against this DIP. I am familiar with the author here, he is very involved with the C++<->D compatibility side of things. He knows the pain from first hand experience. Alright we're talking about a change that have been on hold for almost 10 years, if it was simple it would already been done. In this thread we saw some other concerns been emerged. Finally I only know the author by his postings in this forum, and I don't have anything personally against him. Donald.
Re: DIP 1017--Add Bottom Type--Formal Assessment
On Wed, Jan 30, 2019 at 02:05:37PM +, Mike Parker via Digitalmars-d-announce wrote: > Given the nature of the feedback in both review rounds this DIP has > gone through, Walter has decided to reject his own DIP. He still > believes there is a benefit to adding a bottom type to the language, > but this proposal is not the way to go about it. He hopes to revisit > the issue in the future. [...] Hopefully next time the help of more qualified people in type theory, like Timon, would be solicited, so that a more consistent, logically-sound solution would be proposed. T -- Life is too short to run proprietary software. -- Bdale Garbee
Re: unit-threaded v0.8.0
On Wednesday, 30 January 2019 at 14:27:25 UTC, Atila Neves wrote:
[snip]
--
@Types!(ubyte, byte)
@Types!(int, uint, float)
@UnitTest
void fun(T0, T1)() {
static assert(T0.sizeof == 1);
static assert(T1.sizeof == 4);
}
--
This now generates 6 tests, one for each combination of types,
similarly to what already worked with the @Values UDA.
I'm a little confused on this. What if you have void fun(T0, T1,
T2)) {}, but only two @Types listed? Does it just do the first
two?
Also, there is an example in the readme on @Values of
@Values(1, 2, 3) unittest { assert(getValue!int % 2 == 0); }
What if it's not so easy to create the values? I suppose you
could pass the parameters in @Values to some other function that
will then create what you actually need and then test using that.
Maybe good to provide some more examples of advanced usage?
unit-threaded v0.8.0
New release of unit-threaded, the advanced test framework for D:
https://code.dlang.org/packages/unit-threaded
Besides bug fixes, the main difference is now cartesian product
of types works as it did for values when it comes to
parameterized tests:
--
@Types!(ubyte, byte)
@Types!(int, uint, float)
@UnitTest
void fun(T0, T1)() {
static assert(T0.sizeof == 1);
static assert(T1.sizeof == 4);
}
--
This now generates 6 tests, one for each combination of types,
similarly to what already worked with the @Values UDA.
DIP 1017--Add Bottom Type--Formal Assessment
Given the nature of the feedback in both review rounds this DIP has gone through, Walter has decided to reject his own DIP. He still believes there is a benefit to adding a bottom type to the language, but this proposal is not the way to go about it. He hopes to revisit the issue in the future. Thanks to everyone who provided feedback.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Wednesday, 30 January 2019 at 04:34:46 UTC, Don wrote: On Wednesday, 30 January 2019 at 03:01:36 UTC, 12345swordy wrote: On Wednesday, 30 January 2019 at 00:25:17 UTC, Don wrote: But what I fail to see is why can't the programmer solve this themselves instead of relying on a new feature that would cause more harm? Donald. ...Did you even read the arguments in the dip? This has been discuss quite a lot in the forums, it even gives you links to them. Well, I read the DIP and the whole forum discussion back in the day, and again I think this will create more harm than benefits the way it was proposed. Donald. I do not accept gut feeling as a valid objection here. The current workarounds is shown to be painful as shown in the dip and in the discussions that it currently link. That *the* motivation here. I am familiar with the author here, he is very involved with the C++<->D compatibility side of things. He knows the pain from first hand experience. -Alex
Re: Spasm 0.1.3 released - with bindings to web apis
On Wednesday, 30 January 2019 at 11:03:13 UTC, WebFreak001 wrote: I install LDC from the arch repositories, which should just be the prebuilt binaries from the ldc repo I think Nope, they aren't. I guess your problem is that you cannot *link* wasm; that will only work with v1.14 for distro packages (without integrated LLD).
Re: Spasm 0.1.3 released - with bindings to web apis
On Wednesday, 30 January 2019 at 08:26:22 UTC, Sebastiaan Koppe wrote: On Wednesday, 30 January 2019 at 00:22:15 UTC, WebFreak001 wrote: the underrun example looks really cool! I'm on linux but I don't use docker Wait, you are on linux. Why doesn't your ldc have wasm target? How did you install it? I will try out making something with spasm soon! Cool. I install LDC from the arch repositories, which should just be the prebuilt binaries from the ldc repo I think
Re: GtkD Blog Post #0005 Now Live
On Wednesday, 30 January 2019 at 09:04:35 UTC, M.M. wrote: On Tuesday, 29 January 2019 at 21:00:10 UTC, Ron Tarrant wrote: Another blog post available at http://gtkdcoding.com Enjoy! PS: And yeah, I'll get around to dubbing at some point. Perhaps after I get the docs parser finished. Do you know whether GTKD is going to wrap GTK+ 3.24? (Currently, it is wrapping the previous version 3.22) According to Mike Wey over on gtkd.org, yes. He mentioned this in response to a question from Antonio back in November 2018. When it'll happen, though, is something you'll have to ask Mike.
Re: GtkD Blog Now Up and Running
On Tuesday, 29 January 2019 at 23:09:57 UTC, Christian Köstlin wrote: I was surprised how simple it is nowadays even in osx. Okay, there's definitely something odd going on with my set up. I followed your directions to the letter and OPTLINK barfed. Here is the output from my first try to compile: d:\example\gtkdtest>dub run Fetching gtk-d 3.8.5 (getting selected version)... Performing "debug" build using C:\D\dmd2\windows\bin\dmd.exe for x86. gtk-d:gtkd 3.8.5: building configuration "library"... gtk-d:gstreamer 3.8.5: building configuration "library"... gtk-d:peas 3.8.5: building configuration "library"... gtk-d:sv 3.8.5: building configuration "library"... gtk-d:vte 3.8.5: building configuration "library"... gtkdtest ~master: building configuration "application"... Linking... OPTLINK (R) for Win32 Release 8.00.17 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html C:\Users\ron\AppData\Local\dub\packages\gtk-d-3.8.5\gtk-d\.dub\build\library-debug-windows-x86-dmd_2082-CDBC653BD18B82F232E46588811160FC\gtkd-3.lib Warning 178: .LIB pagesize exceeds 512 Running .\gtkdtest.exe Edit source/app.d to start your project. And after double-checking, I did it again with this result: d:\gtkdtest>dub run --force Performing "debug" build using C:\D\dmd2\windows\bin\dmd.exe for x86. gtk-d:gtkd 3.8.5: building configuration "library"... gtk-d:gstreamer 3.8.5: building configuration "library"... gtk-d:peas 3.8.5: building configuration "library"... gtk-d:sv 3.8.5: building configuration "library"... gtk-d:vte 3.8.5: building configuration "library"... gtkdtest ~master: building configuration "application"... Linking... OPTLINK (R) for Win32 Release 8.00.17 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html C:\Users\ron\AppData\Local\dub\packages\gtk-d-3.8.5\gtk-d\.dub\build\library-debug-windows-x86-dmd_2082-CDBC653BD18B82F232E46588811160FC\gtkd-3.lib Warning 178: .LIB pagesize exceeds 512 Error: linker exited with status 1 C:\D\dmd2\windows\bin\dmd.exe failed with exit code 1. Those were from the standard command shell. I tried it with Git Bash as well and got the same results. And that's why I haven't been using dub. I got things to work with dmd and like they say, if it ain't broke... :) You said you're on OSX, right? Is it possible that dub just isn't as cooperative on Windows 10? Of course, if you can see something in this output that hints at a fix, please let me know.
Re: GtkD Blog Now Up and Running
On Saturday, 26 January 2019 at 16:53:18 UTC, Antonio Corbi wrote: [1] https://sites.google.com/site/gtkdtutorial/ [2] http://britseyeview.com/software/articles/gsgtkd.html [3] https://gitlab.com/csoriano/GtkDApp Took a look this morning. I'd come across the Brit's Eye View articles, but not the others. As I'm about to write something on menus, these will definitely come in handy. Thanks, Antonio.
Re: GtkD Blog Post #0005 Now Live
On Tuesday, 29 January 2019 at 21:00:10 UTC, Ron Tarrant wrote: Another blog post available at http://gtkdcoding.com Enjoy! PS: And yeah, I'll get around to dubbing at some point. Perhaps after I get the docs parser finished. Do you know whether GTKD is going to wrap GTK+ 3.24? (Currently, it is wrapping the previous version 3.22)
Re: DIP 1016 should use expression lowering, not statement lowering
On Tuesday, 29 January 2019 at 11:52:40 UTC, Andrei Alexandrescu wrote: Where should the temporary go? Doesn't D already specify allocation and lifetime of temporaries? AIU the DIP doesn't invent the notion of a temporary.
Re: Spasm 0.1.3 released - with bindings to web apis
On Wednesday, 30 January 2019 at 00:22:15 UTC, WebFreak001 wrote: the underrun example looks really cool! I'm on linux but I don't use docker Wait, you are on linux. Why doesn't your ldc have wasm target? How did you install it? I will try out making something with spasm soon! Cool.
