Re: DIP 1016--ref T accepts r-values--Formal Assessment

2019-01-30 Thread Andrei Alexandrescu via Digitalmars-d-announce

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

2019-01-30 Thread Andrei Alexandrescu via Digitalmars-d-announce

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 cause

Re: DIP 1016--ref T accepts r-values--Formal Assessment

2019-01-30 Thread Andrei Alexandrescu via Digitalmars-d-announce

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

2019-01-30 Thread Manu via Digitalmars-d-announce
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

2019-01-30 Thread Mike Parker via Digitalmars-d-announce
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

2019-01-30 Thread Steven Schveighoffer via Digitalmars-d-announce

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

2019-01-30 Thread Steven Schveighoffer via Digitalmars-d-announce

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

2019-01-30 Thread Manu via Digitalmars-d-announce
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

2019-01-30 Thread Manu via Digitalmars-d-announce
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

2019-01-30 Thread Nicholas Wilson via Digitalmars-d-announce

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

2019-01-30 Thread Nicholas Wilson via Digitalmars-d-announce
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--ref T accepts r-values--Formal Assessment

2019-01-30 Thread Nicholas Wilson via Digitalmars-d-announce

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 ;)


Re: DIP 1016 should use expression lowering, not statement lowering

2019-01-30 Thread Steven Schveighoffer via Digitalmars-d-announce

On 1/30/19 9:20 PM, Steven Schveighoffer wrote:

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.



I came up with this idea based on tempCString, but it doesn't work:

struct RV(T)
{
T theThing;
ref T getIt() { return theThing; }
alias getIt this;
}

auto rv(T)(T t)
{
import std.algorithm : move;
return RV!T(move(t));
}


Of course, we'd need to suppress destructors here potentially.

I tried to use it:

import std.stdio;
void foo(ref int i) {writeln("i is ", i);}
void main()
{
foo(1.rv);
}

But it fails:

Error: function testrvalue.foo(ref int i) is not callable using argument 
types (RV!int)
   cannot pass rvalue argument rv(1) of type RV!int to parameter 
ref int i


If I manually execute the alias this, it works:

foo(1.rv.getIt)

So I don't get why it doesn't work. But if that was fixed, could be a 
potential workaround without requiring a DIP.


-Steve


Re: DIP 1016 should use expression lowering, not statement lowering

2019-01-30 Thread Steven Schveighoffer via Digitalmars-d-announce

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

2019-01-30 Thread Manu via Digitalmars-d-announce
On Wed, Jan 30, 2019 at 1:05 PM Andrei Alexandrescu via
Digitalmars-d-announce  wrote:
>
> 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.

What? `expr` must be an rvalue... if it's not, then none of this applies.


> > 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)
> 

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?

> 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.

> Again (this is not a rhetorical or sarcastic question): are you sure DIP
> 1016 expresses what you are trying to accomplish?

Fairly certain.

> > 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.

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".


Re: DIP 1016--ref T accepts r-values--Formal Assessment

2019-01-30 Thread Manu via Digitalmars-d-announce
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

2019-01-30 Thread Paolo Invernizzi via Digitalmars-d-announce
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

2019-01-30 Thread sanjayss via Digitalmars-d-announce

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

2019-01-30 Thread Mike Wey via Digitalmars-d-announce

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

2019-01-30 Thread kinke via Digitalmars-d-announce
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

2019-01-30 Thread Andrei Alexandrescu via Digitalmars-d-announce

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

2019-01-30 Thread Johannes Loher via Digitalmars-d-announce
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

2019-01-30 Thread bauss via Digitalmars-d-announce

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

2019-01-30 Thread H. S. Teoh via Digitalmars-d-announce
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

2019-01-30 Thread Andrei Alexandrescu via Digitalmars-d-announce

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

2019-01-30 Thread 12345swordy via Digitalmars-d-announce

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

2019-01-30 Thread Simen Kjærås via Digitalmars-d-announce

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

2019-01-30 Thread Jacob Carlborg via Digitalmars-d-announce

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

2019-01-30 Thread Jacob Carlborg via Digitalmars-d-announce

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

2019-01-30 Thread Jacob Carlborg via Digitalmars-d-announce

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

2019-01-30 Thread 12345swordy via Digitalmars-d-announce

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

2019-01-30 Thread Antonio Corbi via Digitalmars-d-announce

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

2019-01-30 Thread Manu via Digitalmars-d-announce
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

2019-01-30 Thread Manu via Digitalmars-d-announce
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

2019-01-30 Thread Neia Neutuladh via Digitalmars-d-announce
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

2019-01-30 Thread Don via Digitalmars-d-announce

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

2019-01-30 Thread H. S. Teoh via Digitalmars-d-announce
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

2019-01-30 Thread jmh530 via Digitalmars-d-announce

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

2019-01-30 Thread Atila Neves via Digitalmars-d-announce

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

2019-01-30 Thread Mike Parker via Digitalmars-d-announce
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

2019-01-30 Thread 12345swordy via Digitalmars-d-announce

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

2019-01-30 Thread kinke via Digitalmars-d-announce

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

2019-01-30 Thread WebFreak001 via Digitalmars-d-announce
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

2019-01-30 Thread Ron Tarrant via Digitalmars-d-announce

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

2019-01-30 Thread Ron Tarrant via Digitalmars-d-announce
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

2019-01-30 Thread Ron Tarrant via Digitalmars-d-announce

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

2019-01-30 Thread M.M. via Digitalmars-d-announce

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

2019-01-30 Thread Kagamin via Digitalmars-d-announce
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

2019-01-30 Thread Sebastiaan Koppe via Digitalmars-d-announce

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.