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

2019-02-03 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 2/1/19 8:15 PM, 12345swordy wrote:

On Friday, 1 February 2019 at 23:24:44 UTC, Olivier FAURE wrote:

On Friday, 1 February 2019 at 09:10:15 UTC, aliak wrote:
Shouldn't doubleMyValue(pt.x) be a compiler error if pt.x is a 
getter? For it not to be a compile error pt.x should also have a 
setter, in which case the code needs to be lowered to something else:


The thing is, D doesn't really differentiate between a getter and any 
other method.


So with DIP-1016, when given

    doubleMyValue(pt.x);

The compiler would assume the programmer means
- Call pt.x()
- Store the result in a temporary
- Pass that temporary as a ref parameter to doubleMyValue

At no point is the compiler aware that the user intends for x to be 
interpreted as a getter.


Languages like c# solve this problem by disallowing passing property to 
ref parameter arguments.


Such would be a good conservative approach for us too. We can relax it 
later if we come with a good idea.


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

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

On 1/31/19 4:42 PM, Olivier FAURE wrote:

On Thursday, 31 January 2019 at 16:38:42 UTC, Steven Schveighoffer wrote:

Yeah, that's already a thing that ref in D doesn't protect against:


It took me a while to understand what the compiler was doing.

This really feels like something that shouldn't compile.


The proposal could actually disallow rvalues that have lvalue syntax, 
such as "symbol", "symbol[expr]", "symbol.symbol", 
"symbol.symbol[expr]", etc. Ugh. Gets hairy quickly.


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

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

On 1/31/19 11:38 AM, Steven Schveighoffer wrote:

On 1/31/19 11:04 AM, Olivier FAURE wrote:

On Thursday, 31 January 2019 at 02:10:05 UTC, Manu wrote:

I still can't see a truck-sized hole.


I don't know if it's truck-sized, but here's another corner case:

 int doubleMyValue(ref int x) {
 x *= 2;
 return x;
 }

 Point pt;
 pt.x = 5;
 pt.y = foobar();

 doubleMyValue(pt.x);
 assert(pt.x == 10);

Question: in the above code, will the assertion pass?

Answer: it depends on Point's implementation. If x is a member 
variable, then yes. If it's a getter, then doubleMyValue will take a 
rvalue and x won't be mutated and the assertion will fail.


I think this is a non-trivial conceptual problem.


Yeah, that's already a thing that ref in D doesn't protect against:

struct Point
{
    private int _x, _y;
    ref int x() { return _x; }
    ref int y() { return _y; }
}

struct Rect
{
    private Point _origin, _lengths;
    Point origin() { return _origin; }
    Point lengths() { return _lengths; }
    void origin(Point p) { _origin = p; }
    void lengths(Point p) { _lengths = p; }
}

Rect r;
r.origin = Point(1, 2);
r.lengths = Point(5, 5);
doubleMyValue(r.lengths.x);
assert(r.lengths.x == 10); // fail

-Steve


Affirmative. This discussion should be part of the revised DIP along 
with an assessment of its gravity.


Goes the same with scope-level variables replaced with homonym functions 
that return rvalues.



Andrei


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 

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 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 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 should use expression lowering, not statement lowering

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

On 1/29/19 10:57 AM, Adam D. Ruppe wrote:

On Tuesday, 29 January 2019 at 15:48:23 UTC, Andrei Alexandrescu wrote:

On 1/29/19 10:44 AM, Nicholas Wilson wrote:

  if (auto val = expr(); val) { ... },


Since we don't have these constructs, lowering would need to explain 
what happens here.



Nitpick, but D has something very similar to that:

if(auto val = expr()) { ... }

it just depends on val implicitly casting to bool.


It's okay if the resulting code is ugly, it won't be user-visible.


We do have to be careful about this - error messages sometimes leak that 
ugly code out.


Yah, it did happen in the past that implementations have been switched 
from lowering to a dedicated case. Lowerings do remain a terrific tool 
for conveying semantics and DIP authors should not worry about 
implementation details.


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

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

On 1/29/19 10:44 AM, Nicholas Wilson wrote:

On Tuesday, 29 January 2019 at 11:52:40 UTC, 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.


On the contrary, an expression lowering cannot inject temporary 
declarations and is impossible.


The correct lowering in the case for `if` & friends follows the form of 
C++ initialiser conditions(?) i.e:


  if (auto val = expr(); val) { ... },


Since we don't have these constructs, lowering would need to explain 
what happens here. Not difficult, but would be nice if we could avoid.



  or the slightly more ugly valid D:

  if ((){return expr(); }()) { ... }

this lambdification will work for just about anything: if, while, assert...


Yes, converting to lambdas is nice and easy and requires no statement 
enumeration - just lower expressions to lambdas and be done with it. 
It's okay if the resulting code is ugly, it won't be user-visible.


DIP 1016 should use expression lowering, not statement lowering

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

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.



Andrei


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

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

On 1/29/19 6:45 AM, Andrei Alexandrescu wrote:
It is truly remarkable that DIP 1016 provides not only a solution to the 
problem, but almost neglects to mention it.


Meant "...not only no solution..."


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

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

On 1/29/19 3:35 AM, Manu wrote:

1. All of this is more useful criticism than the official and final
criticism affixed to the rejection, which when revised to remove the
incorrect criticisms, is basically left with the text "The Language
Maintainers found other issues with the proposal, most of which may
have been remedied through simple revision"


No. This is a nonnegotiable matter:

void bump(ref int x) { ++x; }
short y = 42;
bump(y);
assert(y == 43); // fails

The code above should not compile. The DIP allows it to compile. We 
didn't see how the DIP can be lightly edited to fix this problem, so we 
recommended a complete rethinking and rewrite.



2. All of this criticism could have been given at any point in the
past half a year or so prior to submission, and that would have been
appreciated, rather than wasting our time.


We have given this criticism ever since ten years ago when you brought 
the matter up. Literally every time, including in person. Whenever you 
said "why not bind rvalues to ref?" we religiously replied with 
(paraphrased of course) "We are worried about rvalues resulting from 
implicit conversion of lvalues. You'd need to find a solution to that."


It is truly remarkable that DIP 1016 provides not only a solution to the 
problem, but almost neglects to mention it.



3. "It does not influence our decision and should not be construed as
an essential aspect of the review"  <--  Then why did it feature as
one of just 3 core criticism in the rejection text? And supplied as
one of the 2 reasons that could not "have been remedied through simple
revision".


If the matter above can be resolve through simple revision that would be 
great. I don't think it can, but would love to be proven wrong!



4. "Under DIP 1016, a call with any T[] will silently "succeed" by
converting the slice to void[]"  <--  Do you mean "... with any T[]
rvalue ..."? What would be the aim of that call? Can you suggest a
particularly sinister construction?


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

By applying the lowering rules in the DIP (including your pending 
revision), the code is lowered to:


int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
void[] __temp0 = a;
if (alloc.reallocate(__temp0, 200 * int.sizeof)
{
assert(a.length == 200);
}

The code is far from sinister. But the assertion will fail.

I want to make sure there is mutual understanding that:

1. DIP 1016 proposes this semantics
2. We do not accept this semantics

Even if there is no agreement with (2), these are facts that I want to 
make sure are understood by everyone involved - you, us, the rest of the 
community.



5. "and recommended that it be rewritten simply because it would be
easier and would engender a stronger DIP."  <--  I wrote the DIP I
wrote... your official feedback affixed to the bottom of the DIP was
pretty much entirely unhelpful, almost offensively so. I would just
write the same DIP if I started again. I genuinely hope someone can be
bothered to do this. After 10 years on this, I think I'm over it.


I am sorry you found the review unfit for your needs. I thought it puts 
the main matter plain and simple: we do not accept code like this:


void bump(ref int x) { ++x; }
short y = 42;
bump(y);
assert(y == 43); // fails

Honest, I don't think you have spent 10 years on this DIP. It is not 
thorough work and fails to address the main problem it was supposed to 
address: The one above.



6. "This result was frustrating and disheartening on our side, too: a
stronger DIP ..."  <--  I'm sorry you hated it. You could have
reviewed it at any point, made suggestions at any point, written it
yourself, or encouraged someone competent to do it.


We didn't hate it. We made suggestions literally every time you brought 
up the issue over the past decade. For my part, I have no idea what more 
input I could have provided. "Solve the rvalues coming from implicit 
conversions" is all feedback the DIP needs.



7. Your general tone is superior, as usual.


No need to attempt to make this personal, and claim the moral ground in 
the process. Nobody is after you. We all want the D language to become 
better. The DIP is not good. This is what it is.


All is not lost - the DIP is a good inspiration for a couple of ideas 
that deserve investigation. It seems that allowing _only_ rvalues to be 
bound to ref may work. I'm cautious because there may be cases we didn't 
think of.



Andrei


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

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

On 1/29/19 6:38 AM, Nicholas Wilson wrote:

On Tuesday, 29 January 2019 at 08:35:11 UTC, Manu wrote:

4. "Under DIP 1016, a call with any T[] will silently "succeed"  by
converting the slice to void[]"  <--  Do you mean "... with any T[]  
rvalue ..."? What would be the aim of that call? Can you suggest a 
particularly sinister construction?


I _think_ what is meant is:

void[] allocate(size_t size);
bool reallocate(ref void[] b, size_t s);
void deallocate(ref void[]);

T[] arr = allocate(42);
arr.reallocate(8192); // reallocates a temporary as T[] is cast to void
arr.deallocate(); // double free


Affirmative. (Just wrote about the same in another post). Thanks very much.

Andrei



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

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

On 1/29/19 1:01 AM, Manu wrote:

This DIP is about passing rvalues to ref... so the issue you describe
passing lvalues to ref does not apply here.
There is no suggestion to change lvalue rules anywhere in this DIP.


The problem is with rvalues resulting as temporaries from lvalues. As in:

void bump(ref int x) { ++x; }
short y = 42;
bump(y);
assert(y == 43); // oops

This is a smoking gun. If DIP 1016 does not propose allowing the code 
above, it has caused a gross misunderstanding. Similarly, you mention in 
a different response:



4. "Under DIP 1016, a call with any T[] will silently "succeed" by
converting the slice to void[]"  <--  Do you mean "... with any T[]
rvalue ..."? What would be the aim of that call? Can you suggest a
particularly sinister construction?


If your intent was to NOT allow rvalues resulting from conversions, it 
didn't come through at all. On the contrary, some examples suggest DIP 
1016 _does_ allow it, as in this example:



This inconvenience extends broadly to every manner of rvalue passed to 
functions, including:


...
fun(my_short); // implicit type conversions (ie, short->int promotion)


The reader assumes since the DIP characterizes passing a short lvalue to 
a ref int is an inconvenience, the DIP has set out to resolve it.


The lowering rules proposed by DIP 1006 prescribe the following:

void bump(ref int x) { ++x; }
short y = 42;
bump(y);
===>
void bump(ref int x) { ++x; }
short y = 42;
{
int __temp0 = y;
bump(__temp0);
}

So... yes, lvalues do (undesirably) get converted to rvalues of a 
different type according to the DIP.


Are you sure the DIP expresses what you are trying to accomplish?


Andrei




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

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

On 1/28/19 5:23 PM, Steven Schveighoffer wrote:

I already see this kind of bug all the time with alias this.


Can you please post more detail? It may be of relevance to future work.


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

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

On 1/28/19 1:00 PM, Andrei Alexandrescu wrote:

On 1/24/19 3:01 PM, kinke wrote:

On Thursday, 24 January 2019 at 09:49:14 UTC, Manu wrote:

We discussed and concluded that one mechanism to mitigate this issue
was already readily available, and it's just that 'out' gains a much
greater sense of identity (which is actually a positive side-effect if
you ask me!).
You have a stronger motivation to use 'out' appropriately, because it
can issue compile errors if you accidentally supply an rvalue.


`out` with current semantics cannot be used as drop-in replacement for 
shared in-/output ref params, as `out` params are default-initialized 
on entry. Ignoring backwards compatibility for a second, I think 
getting rid of that would actually be beneficial (most args are 
probably already default-initialized by the callee in the line above 
the call...) - and I'd prefer an explicitly required `out` at the call 
site (C# style), to make the side effect clearly visible.


I'd have otherwise proposed a `@noRVal` param UDA, but redefining 
`out` is too tempting indeed. ;)


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

Whether existing keyword combinations ("in", "out", "ref" etc) could be 
used is a secondary point.


The advantage is there's a simple and clear path forward for API 
definition and use.



Andrei


One more thought.

The main danger is restricted to a specific conversion: lvalue of type T 
is converted to ref of type U. That way both the caller and the function 
writer believe the value gets updated, when in fact it doesn't. Consider:


real modf(real x, ref real i);

Stores integral part in i, returns the fractional part. At this point 
there are two liabilities:


1. User passes the wrong parameter type:

double integral;
double frac = modf(x, integral);
// oops, integral is always NaN

The function silently converts integral from double to real and passes 
the resulting temporary into the function. The temporary is filled and 
lost, leaving user's value unchanged.


2. The API gets changed:

// Fine, let's use double
real modf(real x, ref double i);

At this point all correct callers are silently broken - everybody who 
correctly used a real for the integral part now has their call broken 
(real implicitly converts to a double temporary, and the change does not 
propagate to the user's value).


(If the example looks familiar it may be because of 
https://dlang.org/library/std/math/modf.html.)


So it seems that the real problem is that the participants wrongly 
believe an lvalue is updated.


But let's say the caller genuinely doesn't care about the integral part. 
To do so is awkward:


real unused;
double frac = modf(x, unused);

That code isn't any better or less dangerous than:

double frac = modf(x, double());

Here the user created willingly created an unnamed temporary of type 
double. Given that there's no doubt the user is not interested in that 
value after the call, the compiler could (in a proposed semantics) allow 
the conversion of the unnamed temporary to ref.


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.



Andrei


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

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

On 1/24/19 3:01 PM, kinke wrote:

On Thursday, 24 January 2019 at 09:49:14 UTC, Manu wrote:

We discussed and concluded that one mechanism to mitigate this issue
was already readily available, and it's just that 'out' gains a much
greater sense of identity (which is actually a positive side-effect if
you ask me!).
You have a stronger motivation to use 'out' appropriately, because it
can issue compile errors if you accidentally supply an rvalue.


`out` with current semantics cannot be used as drop-in replacement for 
shared in-/output ref params, as `out` params are default-initialized on 
entry. Ignoring backwards compatibility for a second, I think getting 
rid of that would actually be beneficial (most args are probably already 
default-initialized by the callee in the line above the call...) - and 
I'd prefer an explicitly required `out` at the call site (C# style), to 
make the side effect clearly visible.


I'd have otherwise proposed a `@noRVal` param UDA, but redefining `out` 
is too tempting indeed. ;)


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

Whether existing keyword combinations ("in", "out", "ref" etc) could be 
used is a secondary point.


The advantage is there's a simple and clear path forward for API 
definition and use.



Andrei


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

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

On 1/24/19 2:18 AM, Mike Parker wrote:
Walter and Andrei have declined to accept DIP 1016, "ref T accepts 
r-values", on the grounds that it has two fundamental flaws that would 
open holes in the language. They are not opposed to the feature in 
principle and suggested that a proposal that closes those holes and 
covers all the bases will have a higher chance of getting accepted.


You can read a summary of the Formal Assessment at the bottom of the 
document:


https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md


Hi everyone, I've followed the responses to this, some conveying 
frustration about the decision and some about the review process itself. 
As the person who carried a significant part of the review, allow me to 
share a few thoughts of possible interest.


* Fundamentally: a DIP should stand on its own and be judged on its own 
merit, regardless of rhetoric surrounding it, unstated assumptions, or 
trends of opinion in the forums. There has been a bit of material in 
this forum discussion that should have been argued properly as a part of 
the DIP itself.


* The misinterpretation of the rewrite (expression -> statement vs. 
statement -> statement) is mine, apologies. (It does not influence our 
decision and should not be construed as an essential aspect of the 
review.) The mistake was caused by the informality of the DIP, which 
shows rewrites as a few simplistic examples instead of a general rewrite 
rule. Function calls are expressions, so I naturally assumed the path 
would be to start with the function call expression. Formulating a 
general rule as a statement rewrite is possible but not easy and fraught 
with peril, as discussion in this thread has shown. I very much 
recommend going the expression route (e.g. with the help of lambdas) 
because that makes it very easy to expand to arbitrarily complex 
expressions involving function calls. Clarifying what temporaries get 
names and when in a complex expression is considerably more difficult 
(probably not impossible but why suffer).


* Arguments of the form: "You say DIP 1016 is bad, but look at how bad 
DIP XYZ is!" are great when directed at the poor quality of DIP XYZ. 
They are NOT good arguments in favor of DIP 1016.


* Arguments of the form "Functions that take ref parameters just for 
changing them are really niche anyway" should be properly made in the 
DIP, not in the forums and assumed without stating in the DIP. Again, 
what's being evaluated is "DIP" not "DIP + surrounding rhetoric". A good 
argument would be e.g. analyzing a number of libraries and assess that 
e.g. 91% uses of ref is for efficiency purposes, 3% is unclear, and only 
6% is for side-effect purpose. All preexisting code using ref parameters 
written under the current rule assumes that only lvalues will be bound 
to them. A subset of these functions take by ref for changing them only. 
The DIP should explain why that's not a problem, or if it is one it is a 
small problem, etc. My point is - the DIP should _approach_ the matter 
and build an argument about it. One more example from preexisting code 
for illustration, from the standard library:


// in the allocators API
bool expand(ref void[] b, size_t delta);
bool reallocate(ref void[] b, size_t s);

These primitives modify their first argument in essential ways. The 
intent is to fill b with the new slice resulted after 
expansion/reallocation. Under the current rules, calling these 
primitives is cumbersome, but usefully so because the processing done 
requires extra care if typed data is being reallocated. Under DIP 1016, 
a call with any T[] will silently "succeed" by converting the slice to 
void[], passing the temporary to expand/reallocate, then return as if 
all is well - yet the original slice has not been changed. The DIP 
should create a salient argument regarding these situations (and not 
only this example, but the entire class). It could perhaps argue that:


- Such code is bad to start with, and should not have been written.
- Such code is so rare, we can take the hit. We then have a 
recommendation for library writers on how to amend their codebase (use 
@disable or some other mechanisms).

- The advantages greatly outweigh this problem.
- The bugs caused are minor easy to find.
- ...

Point being: the matter, again should be _addressed_ by the DIP.

* Regarding our recommendation that the proposal is resubmited as a 
distinct DIP as opposed to a patch on the existing DIP: this was not 
embracing bureaucracy. Instead, we considered that the DIP was too poor 
to be easily modified into a strong proposal, and recommended that it be 
rewritten simply because it would be easier and would engender a 
stronger DIP.


* Regarding the argument "why not make this an iterative process where 
concerns are raised and incrementally addressed?" We modeled the DIP 
process after similar processes - conference papers, journal papers, 
proposals in other languages. There is a proposal by one 

Top Five World’s Most Underrated Programming Languages

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

Of possible interest:

https://www.technotification.com/2019/01/most-underrated-programming-languages.html


Re: My Meeting C++ Keynote video is now available

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

On 1/12/19 7:21 PM, Bastiaan Veelo wrote:

On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu wrote:

https://youtube.com/watch?v=tcyb1lpEHm0

If nothing else please watch the opening story, it's true and quite 
funny :o).


Now as to the talk, as you could imagine, it touches on another 
language as well...



Andrei


Top notch, as usual.

Nice progression from “another language” through “the other language”, 
“d (other) language” to finally just “D language“ :-)


Bastiaan.


Glad you noticed. It was deliberate.


My Meeting C++ Keynote video is now available

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

https://youtube.com/watch?v=tcyb1lpEHm0

If nothing else please watch the opening story, it's true and quite 
funny :o).


Now as to the talk, as you could imagine, it touches on another language 
as well...



Andrei


Shopping on Amazon on Prime Day (and beyond)? Support the D language!

2018-07-17 Thread Andrei Alexandrescu via Digitalmars-d-announce

Amazon has a nonprofit arm:

https://smile.amazon.com

Go there and choose The D Language Foundation as your charity of choice, 
then shop normally through smile.amazon.com. A fraction of your 
expenditure will go to the Foundation.



Thanks,

Andrei


Vision document for H1 2018

2018-03-09 Thread Andrei Alexandrescu via Digitalmars-d-announce
Hello, the vision document of the Founation for the first six months of 
2018 is here:


https://wiki.dlang.org/Vision/2018H1

In addition to the expected items, we have a new top-level priority - 
locking down the language definition. This is in recognition of the fact 
that we need a precise definition of the language going forward.



Thanks,

Andrei


Re: An optional/maybe type with range semantics

2018-02-28 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 2/28/18 12:54 PM, Andrei Alexandrescu wrote:

On 2/25/18 8:03 PM, aliak wrote:

Alo,

Just finished up a first take on an optional type for D. It's 
essentially a mix of Nullable and std.range.only, but with a lot more 
bells and whistles. I would love to hear any feedback on code, or 
features, or bad design or potential for better designs from anyone 
who's interested :)


Code: https://github.com/aliak00/optional
Dub: https://code.dlang.org/packages/optional
Docs: https://aliak00.github.io/optional/


Did you take a look at https://dlang.org/library/std/range/only.html? -- 
Andrei


Ah, sorry I missed that you mentioned it. -- Andrei



Re: An optional/maybe type with range semantics

2018-02-28 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 2/25/18 8:03 PM, aliak wrote:

Alo,

Just finished up a first take on an optional type for D. It's 
essentially a mix of Nullable and std.range.only, but with a lot more 
bells and whistles. I would love to hear any feedback on code, or 
features, or bad design or potential for better designs from anyone 
who's interested :)


Code: https://github.com/aliak00/optional
Dub: https://code.dlang.org/packages/optional
Docs: https://aliak00.github.io/optional/


Did you take a look at https://dlang.org/library/std/range/only.html? -- 
Andrei




Please submit to DConf 2018!

2018-02-21 Thread Andrei Alexandrescu via Digitalmars-d-announce
With the Feb 25 deadline looming, allow me to holler to everyone who has 
worked on great things in the D language through the past year: please 
make a DConf 2018 submission!


By all measures there's been significant pick up in contributions to the 
D language during the recent months, and it would be awesome to have 
that solid work reflected in a strong program in Munich.


What we need on Feb 25 are your title, abstract, and bio. What we need 
on your talk day is your lovable self talking about your great idea.


Giving a talk at DConf is a high service to the D language community. In 
recognition of that, the D Language Foundation reimburses travel and 
accommodation expenses for speakers. Please contact Michael Parker 
(soc...@dlang.org) for details.



Thanks,

Andrei


Re: D's Newfangled Name Mangling

2017-12-22 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 12/20/17 8:57 AM, Mike Parker wrote:
Many thanks to Rainer for his insightful new article for the D Blog 
outlining the new name mangling algorithm. He talks about the old 
implementation and its limitations before going into the details of the 
new one. It's a topic I had never considered digging into before, even 
when the big Voldemort issue first popped up, but now I find it 
interesting.


The blog
https://dlang.org/blog/2017/12/20/ds-newfangled-name-mangling/

Reddit
https://www.reddit.com/r/programming/comments/7l1h36/ds_newfangled_name_mangling/ 


Hi folks, the discussion in the announce forum is most welcome but 
statistically very few people read the forum. Please direct discussions 
to the reddit group, which enjoys a broader audience. Sadly right now 
the sparse reddit discussion makes the reception look worse than it 
actually was. -- Andrei


Meet our new scholarship recipient, Alexandru Jercaianu

2017-10-02 Thread Andrei Alexandrescu via Digitalmars-d-announce
Hello everyone, it is my pleasure to announce that Alexandru Jercaianu, 
a starting MSc student at University "Politehnica" Bucharest, is 
recipient of our scholarship.


Alex is up and running working on his bootcamp tasks. Currently he is 
attempting unsuccessfully to post in our general group :o).


Please join me in welcoming Alexandru!


Andrei


Re: Boston D Meetup: Strawman Structs

2017-07-28 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 7/25/17 5:50 AM, John Colvin wrote:

On Sunday, 2 July 2017 at 10:35:49 UTC, Steven Schveighoffer wrote:
I'll have a short presentation on a weird trick I discovered while 
writing some MySQL serialization code. Hope you can attend!


https://www.eventbrite.com/e/d-lang-presentation-strawman-structs-tickets-35120523431 



-Steve


Is there a written summary of the idea? Or is there a specific point in 
the video someone could point me to?


What I can definitely say is it's a very interesting technique worth 
slogging through probably poor audio etc. It's really a concept language 
without a language. Very inspiring work. -- Andrei


Re: H2 2017 Vision Document

2017-07-25 Thread Andrei Alexandrescu via Digitalmars-d-announce

On Tuesday, 25 July 2017 at 15:09:37 UTC, Mike Parker wrote:

On Tuesday, 25 July 2017 at 14:16:18 UTC, Atila Neves wrote:



How would one go about volunteering?

Atila


I think you just did.


Atila, welcome to Team Phobos.


Re: DIP 1010--Static foreach--Accepted

2017-07-17 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 7/17/17 8:38 AM, Steven Schveighoffer wrote:
What is the resolution of how break statements affect static 
foreach/foreach?


We initially allowed break and continue to refer to the enclosing 
statement, but upon further consideration we will make it an error. This 
allows us to collect more experience with the feature and leaves us the 
option to permit break/continue later on. I have contacted Timon about 
the matter. Thanks! -- Andrei


static foreach is now in github master

2017-07-17 Thread Andrei Alexandrescu via Digitalmars-d-announce
For those who want to play with our new static foreach feature and are 
willing to take the steps to building their own dmd, the feature is now 
merged in master: https://github.com/dlang/dmd/pull/6760


Happy hacking!

Andrei


Re: Munich D Meetup July 2017

2017-07-16 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 7/14/17 5:32 PM, Dragos Carp wrote:

Bump the thread, the next Munich D Meetup is getting closer.


Greetings to the D community in München, which seems to be our strongest 
local group. Hoping for a solid turnout at this meeting because it may 
prompt a larger event later on. Would be happy to visit and give a talk 
in the fall! I'll let the local leaders give folks more information at 
the upcoming meetup. -- Andrei


Re: DIP 1010--Static foreach--Accepted

2017-07-16 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 7/16/17 9:10 AM, Mike Parker wrote:
Congratulations to Timon Gehr. Not only was his "Static foreach" DIP 
accepted, it picked up a good deal of praise from Walter & Andrei.


Indeed. Kudos to Timon (and thanks Mike for driving the process). This 
is a well done DIP that many others could draw inspiration from. -- Andrei


RedMonk language rankings June 15, 2017

2017-06-24 Thread Andrei Alexandrescu via Digitalmars-d-announce
http://i-programmer.info/news/98-languages/10859-redmonk-rankings-reveal-the-languages-we-love.html 
-- Andrei


Article on i-programmer.info on GDC

2017-06-24 Thread Andrei Alexandrescu via Digitalmars-d-announce

http://i-programmer.info/news/98-languages/10883-d-gets-a-boost-from-gcc.html

Andrei


Re: Ali's talk C++Now 2017: Competitive Advantage with D on Reddit!

2017-06-08 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 6/8/17 5:03 PM, Wulfklaue wrote:

On Thursday, 8 June 2017 at 20:38:33 UTC, Ali Çehreli wrote:
That link doesn't work for me. Besides, I've heard that it's better 
not to click through a link as HN either rates it lower or flags it as 
spam.


Not sure though, I'm just contributing to cargo cult... :)

Ali


Removed the old one and add new one with the full youtube link:

https://news.ycombinator.com/item?id=14517183


Posting direct HN links in any forum is a sure way to have the entry 
classified as spam (HN uses an algorithm that flags as spam many 
accesses that do not have their own site as referrer). -- Andrei


Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-03 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 06/03/2017 11:08 AM, Andrei Alexandrescu wrote:

On 6/2/17 10:17 AM, Mike Parker wrote:
Congratulations are in order for Jared Hanson. Walter and Andrei have 
approved his proposal to remove body as a keyword. I've added a 
summary of their decision to the end of the DIP for anyone who cares 
to read it. In short:


* body temporarily becomes a contextual keyword and is deprecated
* do is immediately allowed in its place
* body is removed and do replaces it fully

Congratulations, Jared!

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md


Congrats to all who worked on this. Next step is to revise the DIP that 
puts the approved option to the fore and mentions the others only as 
other options that have been analyzed. This is because we have an 
"Approved" status but not "Approved Option X". Thanks! -- Andrei


Sorry, was looking at a stale copy. I think the DIP is fine as is. The 
previously discussed options are available as earlier revisions of the 
DIP. -- Andrei


Re: DIP 1003 (Remove body as a Keyword) Accepted!

2017-06-03 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 6/2/17 10:17 AM, Mike Parker wrote:
Congratulations are in order for Jared Hanson. Walter and Andrei have 
approved his proposal to remove body as a keyword. I've added a summary 
of their decision to the end of the DIP for anyone who cares to read it. 
In short:


* body temporarily becomes a contextual keyword and is deprecated
* do is immediately allowed in its place
* body is removed and do replaces it fully

Congratulations, Jared!

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md


Congrats to all who worked on this. Next step is to revise the DIP that 
puts the approved option to the fore and mentions the others only as 
other options that have been analyzed. This is because we have an 
"Approved" status but not "Approved Option X". Thanks! -- Andrei


Re: DCompute is now in the master branch of LDC

2017-05-31 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 5/31/17 6:03 PM, Jonathan M Davis via Digitalmars-d-announce wrote:

On Wednesday, May 31, 2017 18:55:14 bachmeier via Digitalmars-d-announce
wrote:

On Wednesday, 31 May 2017 at 12:28:47 UTC, Nicholas Wilson wrote:

But can we please reduce the bike shedding


Marketing is only bike shedding if you don't care how many people
make use of your work.


That may be true, but given how this was supposed to be a thread on some
great news about this cool library, having most of the posts be about the
name has got to be frustrating.

Yes, the name matters, but this thread has been pretty thoroughly derailed
from its original purpose.

- Jonathan M Davis


You're right. Congratulations Nicholas for this great work and I wish it 
succeeds by any name he chooses for it. -- Andrei




Re: DCompute is now in the master branch of LDC

2017-05-31 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 5/31/17 7:28 PM, Nicholas Wilson wrote:

On Wednesday, 31 May 2017 at 22:15:33 UTC, Wulfklaue wrote:

On Wednesday, 31 May 2017 at 12:28:47 UTC, Nicholas Wilson wrote:
Perhaps there will be scope for renaming if/when this also includes 
graphics when either OpenCL is merged into the Vulkan API or Petar 
Kirov gets Vulkan SPIRV generation going on LLVM, but for now the 
name stays.


People who GPU program are indeed a small group. But you do NOT entice 
other people to try it, when they do not even know a language has this 
feature set. And this comes down to marketing.


Lets post "D has DCompute" or "D has D-GPU"... on Reddit, ycombinator 
and other forum or news site.


What do you think people will more likely click on?



So you don't post either of those titles and instead post "D has 
DCompute: Native heterogeneous computing on GPUs and more, hassle free!"


"D has the invariant qualifier: It means immutable".


Re: DCompute is now in the master branch of LDC

2017-05-31 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 5/30/17 3:23 PM, Jack Stouffer wrote:

On Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote:

I fear the conversation will go like this, like it has for me:

 N: DCompute
 W: What's DCompute?
 N: Enables GPU programming with D
 W: Cool!

instead of:

 N: D-GPU
 W: Cool! I can use D to program GPUs!


This was literally what happened to me when I saw the headline.


I'm in the same camp, and I have a passing familiarity with the domain. 
Worse, only one day after the talk I'd already forgotten and thought 
DCompute does what DHDL does.


It seems there are two paths - either choose an unrelated name and push 
it as a brand (e.g. Amazon, Google, and in our community Phobos or 
Vibe), or choose a name that immediately establishes the library as "the 
D approach to GPGPUs". The name "DCompute" is in an unfortunate corner 
of the branding space.



Andrei


Re: Trip notes from Israel

2017-05-26 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 5/22/17 6:53 PM, cym13 wrote:

On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:
http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/ 
-- Andrei


Now that you are back and could take some time to think this over, would 
you say your trip will influence how you see D's and the D community 
evolution? In what way?


In several ways. To an extent it was a confirmation of things already 
known: We do well on things we focus on (language core, standard 
library, quality of implementation), and less so on things we focus less 
on (soft skills, community building, leadership). I got a clearer notion 
that the latter is an important ingredient.


One thing that several of those people emphasized is we need to improve 
leadership and decision. "You are trying to do democracy and democracy 
doesn't work here" (by a successful serial entrepreneur). Walter and I 
have implicitly fostered a kind of meritocracy whereby it's the 
point/argument that matters. It should be meritocracy of the person - 
good proven contributors have more weight and new people must prove 
themselves before aspiring to influence. Historically, anyone with any 
level of involvement with D could hop on the forum and engage the 
community and its leadership in debate. Subsequently, they'd be 
frustrated with the ensuing disagreement and also get a sense of 
cheapness - if I got to carry this unsatisfactory debate with the 
language creator himself, what kind of an operation is this?


Since anything can be debated by anyone, everything gets debated by 
everyone. Anyone can question any decision at any time and expect a 
response. It's the moral equivalent of everyone in a 5000-person company 
building can expect to stop the CEO on the way to his/her office and 
engage them in a conversation of any length. The net consequence is 
slower progress.


Where we need to be is fostering strong contributions and contributors. 
The strength of one's say is multiplied by his/her contributions (and 
that simply means pulled PRs, successful DIPs - not "won" debates). Many 
successful OSS projects have been quoted as implementing this policy 
successfully.


Every person in the room took a significant fraction of the meeting time 
to tear me a new one about dub and http://code.dlang.org. Each in a 
different place :o). I got to the point where I consider every day spent 
with code.lang.org just sitting there with no ranking, no statistics, no 
voting, no notion of what are the good projects to look at - every such 
day is a liability for us. We really need to improve on that, it is of 
utmost importance and urgency. Martin said he'll be on that in June, but 
we could really use more hands on deck there.


Documentation of vibe.d was also mentioned as an important problem. More 
precisely, it's the contrast between the quality of the project and that 
of the documentation - someone said his team ended up with a different 
(and arguably inferior) product that was better documented. Literally 
they had the same engineer try each for a day. Reportedly it was very 
difficult to even figure whether vibe.d does some specific thing, let 
alone tutorials and examples of how to do it.


Back to community: Successful OSS projects have a hierarchy and follow 
formalized paths and processes for communicating up and down. People are 
willing to work/wait for months on a proposal because they have a sense 
of process and a confidence their proposal, if properly done, will get a 
fair shake. These are good ideas to follow (and indeed I got more 
confirmation that investing in our new DIP process is a good thing to do).


We need to improve the collaboration and tone in the forums and github. 
(I was amazed at how well these business and community leaders knew 
who's who in our community.) We can only assume in the future people 
will peruse our forums/github to decide whether to use D in their 
enterprise. We need to improve on the current disposition toward 
fruitless debate not concluding in decision making. What hurts us the 
most and stands like a sore thumb is the occasional use of abusive 
language. We need to stop that.


Many of these things I had a good sense of before entering the meeting, 
and was on the way toward improving on them. The meeting provided a 
strong confirmation of the importance of these matters, and good ideas 
toward doing better.



Andrei


Generating checked integral operations [WAS: Trip notes from Israel]

2017-05-23 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 05/23/2017 11:37 AM, Stefan Koch wrote:


The compiler does indeed seem to optimize the code somewhat.
Although the generated asm still looks wired.
http://asm.dlang.org/#compilers:!((compiler:dmd_nightly,options:'-dip25+-O+-release+-inline+-m32',source:'import+core.checkedint%3B%0A%0Aalias+T+%3D+ulong%3B%0Aextern+(C)+T+foo(uint+x,+uint+y,+ref+bool+overflow)%0A%7B%0A+++return+mulu(x,+y,+overflow)%3B%0A%7D%0A')),filterAsm:(binary:!t,intel:!t),version:3 


That call enters a different overload:

pragma(inline, true)
uint mulu(uint x, uint y, ref bool overflow)
{
ulong r = ulong(x) * ulong(y);
if (r > uint.max)
overflow = true;
return cast(uint)r;
}

which is of efficiency comparable with code using seto. I'm not too 
worried about that. https://goo.gl/eRXUpr is of interest.



Andrei


Re: Trip notes from Israel

2017-05-23 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 5/22/17 4:51 PM, Johan Engelen wrote:

On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:
http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/ 
-- Andrei


A fun read!

"(Late at night, I double checked. Mozilla’s CheckedInt is just as bad 
as I remembered. They do a division to test for multiplication overflow. 
Come on, put a line of assembler in there! Portability is worth a price, 
just not any price.)"


Shocked: do you use assembly in Checked and cripple the optimizer?!?!
Luckily, no. But LDC and GDC do create the `seto` instruction I think 
you were hinting at:

https://godbolt.org/g/0jUhgs

(LDC doesn't do as good as it could, 
https://github.com/ldc-developers/ldc/issues/2131)


Thanks! Yes, seto is what I thought of - one way or another, it gets 
down to using a bit of machine-specific code to get there. I'll note 
that dmd does not generate seto (why?): https://goo.gl/nRjNMy. -- Andrei




Re: Trip notes from Israel

2017-05-22 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 05/22/2017 11:26 AM, Andrei Alexandrescu wrote:

On 05/22/2017 11:23 AM, Adam D. Ruppe wrote:

On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:

mixin is a statement so it needs a terminator, hence
the semicolon at the very end. In turn, mixin takes
a string (the concatenation of variable op


That actually depends on context! The mixin statement needs 
statements, but the mixin expression takes expressions. Same mixin 
keyword, but if it is in the context of a statement it is a statement 
and in the context of an expression, it is an expression.


---
void main() {
 int payload;
 mixin("++payload;"); // statement, ; required
 int b = mixin("++payload"); // expression, ; would be wrong there 
and cause an error!

}
---

http://dlang.org/spec/expression.html#MixinExpression
http://dlang.org/spec/statement.html#MixinStatement


Yah, didn't want to overload the article (or the discussion) with the 
expression/statement distinction. -- Andrei


Updated the post, it's an interesting point after all. Thanks! -- Andrei


Re: Trip notes from Israel

2017-05-22 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 05/22/2017 11:23 AM, Adam D. Ruppe wrote:

On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:

mixin is a statement so it needs a terminator, hence
the semicolon at the very end. In turn, mixin takes
a string (the concatenation of variable op


That actually depends on context! The mixin statement needs statements, 
but the mixin expression takes expressions. Same mixin keyword, but if 
it is in the context of a statement it is a statement and in the context 
of an expression, it is an expression.


---
void main() {
 int payload;
 mixin("++payload;"); // statement, ; required
 int b = mixin("++payload"); // expression, ; would be wrong there 
and cause an error!

}
---

http://dlang.org/spec/expression.html#MixinExpression
http://dlang.org/spec/statement.html#MixinStatement


Yah, didn't want to overload the article (or the discussion) with the 
expression/statement distinction. -- Andrei


Re: Trip notes from Israel

2017-05-22 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 05/22/2017 11:05 AM, Andrei Alexandrescu wrote:
http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/ 
-- Andrei


Submitted to reddit as well: 
https://www.reddit.com/r/programming/comments/6cntso/from_the_d_blog_introspection_introspection/ 
-- Andrei


Trip notes from Israel

2017-05-22 Thread Andrei Alexandrescu via Digitalmars-d-announce
http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/ 
-- Andrei


Re: [OT] Fast Deterministic Selection

2017-05-22 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 05/20/2017 04:52 PM, Jon Degenhardt wrote:

On Thursday, 18 May 2017 at 15:14:17 UTC, Andrei Alexandrescu wrote:
The implementation is an improved version of what we now have in the D 
standard library. I'll take up the task of updating phobos at a later 
time.


https://www.reddit.com/r/programming/comments/6bwsjn/fast_deterministic_selection_sea_2017_now_with/ 




Andrei


Very nice! Is this materially faster than what is currently in Phobos 
(PR 4815)? That update was a substantial performance win by itself.


--Jon


The code per the paper is faster for more data sets. For the NLP data 
you tested on, speed should be about the same. -- Andrei


[OT] Fast Deterministic Selection

2017-05-18 Thread Andrei Alexandrescu via Digitalmars-d-announce
The implementation is an improved version of what we now have in the D 
standard library. I'll take up the task of updating phobos at a later time.


https://www.reddit.com/r/programming/comments/6bwsjn/fast_deterministic_selection_sea_2017_now_with/


Andrei


Re: Andre's Google Tel Aviv Talk

2017-05-16 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 05/16/2017 11:02 AM, Walter Bright wrote:

On 5/16/2017 7:00 AM, Andrei Alexandrescu wrote:

Same material as my DConf talk, better delivery. Longer, too, however.
-- Andrei


I.e. the Director's Cut.


It's been also on https://news.ycombinator.com/newest as of a few 
minutes ago. -- Andrei


Re: Andre's Google Tel Aviv Talk

2017-05-16 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 05/16/2017 09:51 AM, Mike Parker wrote:

Weka.IO invited Andrei to talk at a meetup at Google Tel Aviv last week.
The video of the talk is online:

https://www.youtube.com/watch?v=es6U7WAlKpQ=youtu.be


Same material as my DConf talk, better delivery. Longer, too, however. 
-- Andrei


Working code in an upcoming PR by Timon Gehr

2017-05-07 Thread Andrei Alexandrescu via Digitalmars-d-announce
Zoom in on the screen for a nice surprise! http://imgur.com/a/qjI4l -- 
Andrei


Re: My D tool projects have moved

2017-05-07 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 5/7/17 10:59 AM, Brian Schott wrote:
I moved DCD, D-Scanner, dfmt, and other D tool projects to the 
dlang-community organization on Github:


https://github.com/dlang-community

This should make things more convenient if I get hit by a bus, decide 
that Malbolge* is the one true programming language, or just take too 
long to review a pull request.


* https://en.wikipedia.org/wiki/Malbolge


Thanks, Brian. BTW you are being missed at DConf! -- Andrei


My slides for tomorrow

2017-05-05 Thread Andrei Alexandrescu via Digitalmars-d-announce

https://erdani.com/dconf2017-slides.pdf -- Andrei


Re: The DConf Experience

2017-04-19 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 4/19/17 11:26 AM, Joakim wrote:


Nice post.  What's the occupancy like for the event so far? Seemed 
pretty full last year, wondering how many more can sign up this year.


There are still available seats. -- Andrei


The Strange Loop Call for Presentations

2017-04-10 Thread Andrei Alexandrescu via Digitalmars-d-announce

https://thestrangeloop.com/cfp.html

Track of interest: Languages - functional programming, logic 
programming, dynamic/scripting languages, new or emerging languages (and 
of course others depending on domain).



Andrei


InfoWorld article on the open sourcing of dmd

2017-04-10 Thread Andrei Alexandrescu via Digitalmars-d-announce

http://www.infoworld.com/article/3188427/application-development/free-at-last-d-languages-official-compiler-is-open-source.html

Andrei


Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

2017-04-09 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 4/9/17 4:56 AM, Atila Neves wrote:
Using std.experimental.allocator? Tired of writing `scope(exit) 
allocator.dispose(foo);` in a language with RAII? Me too:




http://code.dlang.org/packages/automem

Example:

I think the code in the README should be enough to understand what's 
going on. Alpha stuff here but I think the main things missing are weak 
pointers and a ref counted array. Given that I've never had to use 
std::weak_ptr in C++, I'm not in a hurry to implement the former.


Nice work!


Notable design decisions / features:

. The smart pointers are responsible for allocating the memory for the 
container object using the allocator of choice. This is to guarantee 
that one can't allocate and deallocate using different allocators.


Nice!

. The allocator has to be specified as part of the type: this means the 
user can choose how to store it in the smart pointer, which for 
singletons (e.g. Mallocator) or stateless allocators means they can take 
up zero space. If a singleton (or the default theAllocator), the 
allocator doesn't need to be passed in to the constructor, otherwise it 
does. Specifying, e.g. Mallocator also means the relevant code can be 
marked @nogc.


After extensively studying how C++ allocator framework works, I got to 
the notion that making the allocator part of the type is an antipattern.


. RefCounted only increments/decrements the ref count atomically if the 
contained type is `shared`


Great. Can RefCounted itself be shared? I learned this is important for 
composition, i.e. you want to make a RefCounted a field in another 
object that is itself shared, immutable etc.



. RefCounted!(shared T) can be sent to other threads.


Awes.

. UniqueArray behaves nearly like a normal array. You can even append to 
it, but it won't use GC memory (unless, of course, you chose to use 
GCAllocator)!


This may be a great candidate for the standard library.


Andrei


Re: dmd Backend converted to Boost License

2017-04-07 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 04/07/2017 12:01 PM, Jack Stouffer wrote:

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to
relicense it. Thank you, Symantec!


Reddit:
https://www.reddit.com/r/programming/comments/6419py/the_official_d_compiler_is_now_free_as_in_freedom/


Thanks, someone also put it on hackernews - found it by browsing for 
"new" threads. -- Andrei




Mike Parker is the new DIP czar

2017-04-03 Thread Andrei Alexandrescu via Digitalmars-d-announce

Hello,


By this we are happy to announce that Mike Parker graciously agreed to 
take over the role of DIP czar.


DIP management requires a mix of skills (technical, editorial, 
organizational, interpersonal, and literary) that Mike possesses in 
spades. Looking forward to a long and fruitful cooperation.


Please join me in thanking and congratulating Mike!


Andrei


Re: D event in Bucharest

2017-03-18 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 3/18/17 9:35 PM, Jack Stouffer wrote:

On Saturday, 18 March 2017 at 15:02:23 UTC, Andrei Alexandrescu wrote:

I'll give a talk on D at University "Politehnica" Bucharest on Friday,
March 24. Share wide!

https://www.facebook.com/events/267258633731095/


Andrei


Will the talk be recorded?


Trying, but probably not. -- Andrei


D event in Bucharest

2017-03-18 Thread Andrei Alexandrescu via Digitalmars-d-announce
I'll give a talk on D at University "Politehnica" Bucharest on Friday, 
March 24. Share wide!


https://www.facebook.com/events/267258633731095/


Andrei


Re: DConf 2017 Hotel - book now!

2017-03-02 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 03/01/2017 09:24 PM, Walter Bright wrote:

http://www.ibis.com/gb/hotel-5694-ibis-berlin-neukoelln/index.shtml

Last year, some people booked late and it was full and they had to stay
at another hotel.


Thanks Walter. Note: if you want to bunk/offer bunk to a friend, you may 
want to book the 2 twin beds option (same price as the queen bed). -- Andrei


Re: DConf 2017 Early Bird Registration expires Monday!

2017-02-28 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 02/28/2017 02:34 AM, Jacob Carlborg wrote:

On 2017-02-28 07:08, Walter Bright wrote:


I had sent a confirmation email. Unfortunately, there are often problems
with this, as the emails get put in the recipient's spam folder.


Could we please just fix the problem.


It has been fixed on 2/25. Apologies for the annoyance. -- Andrei



Re: DConf 2017 Early Bird Registration expires Monday!

2017-02-25 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 2/25/17 8:25 AM, Moritz Maxeiner wrote:

On Saturday, 25 February 2017 at 07:02:48 UTC, Walter Bright wrote:

http://dconf.org/2017/registration.html

Don't forget, it goes up to $400 after Monday.


Just registered and was returned to http://dconf.org/2017/thankyou.html
afterwards, which yields a 404 error. Not sure if I should laugh or cry.


Thanks for piping up about this. I had the fix locally for a while but 
my credentials weren't working anymore. I have uploaded the page. -- Andrei


Re: Getters/setters generator

2017-01-18 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 1/18/17 5:29 PM, Mark wrote:

I see. Is there a way to call invariant() of a class/struct directly?
That would obviate the need for a particular predicate (copy the class
state, run the setter, check if invariants are satisfied and restore
previous state if they aren't).


It seems painfully obvious the right way is a guarded assignment and 
anything else would be a more or less painful workaround. -- Andrei


Re: Getters/setters generator

2017-01-17 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 1/17/17 12:08 PM, Mark wrote:

On Tuesday, 17 January 2017 at 09:17:56 UTC, Andrei Alexandrescu wrote:

On 1/17/17 9:32 AM, Eugene Wissner wrote:

Ah, well thanks. I don't think it makes much sense since it would be
easier to write a complete setter if the user needs extra checks.
Accessors are there only for the generation of the standard methods,
that just get or set some object property.


Hmmm... that's a bit of a bummer because it helps only the degenerate
case (accessors are there as placeholders for future extensions, and
otherwise offer no protection whatsoever compared to a public value).
The question would be then what would be use cases for the accessors.
Predicated setters are not just a random thing one might want out of
many possibilities, it's a frequent pattern. -- Andrei


Given that D supports class invariants, is there a real need for
predicated setters?


The invariant is evaluated after the setter has taken place, i.e. after 
the object has been corrupted. The setter guard prevents corruption from 
happening.  -- Andrei


Re: Getters/setters generator

2017-01-17 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 1/17/17 9:32 AM, Eugene Wissner wrote:

Ah, well thanks. I don't think it makes much sense since it would be
easier to write a complete setter if the user needs extra checks.
Accessors are there only for the generation of the standard methods,
that just get or set some object property.


Hmmm... that's a bit of a bummer because it helps only the degenerate 
case (accessors are there as placeholders for future extensions, and 
otherwise offer no protection whatsoever compared to a public value). 
The question would be then what would be use cases for the accessors. 
Predicated setters are not just a random thing one might want out of 
many possibilities, it's a frequent pattern. -- Andrei


Re: Getters/setters generator

2017-01-17 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 1/17/17 8:26 AM, Eugene Wissner wrote:

On Friday, 9 December 2016 at 18:53:55 UTC, Andrei Alexandrescu wrote:


Love it, and was toying with similar ideas too. One good extension is
to add a predicate to the setter, which guards the assignment. -- Andrei


What kind of predicate do you mean? Can you give an example please?


Say you have a property "percent". The setter should do an enforce(value 
>= 0 && value <= 100) before the assignment. -- Andrei


Re: Vision document for H1 2017

2017-01-07 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 01/07/2017 02:55 PM, Martin Nowak wrote:

On 01/05/2017 11:00 AM, Basile B. wrote:

I don't known what did you decide in intern but when the discussion
between users was hot (just after version 2.071.1 I think) I've proposed
that:
https://github.com/BBasile/DIPs/blob/3d5e3f81c541c6e23c69555a230b4d42a7bb6de6/DIPs/DIP8484.md


This is superfluous by now. We figured that allowing access to private
fields wouldn't clash with important optimizations, so it can be allowed
via traits.
The visibility of allMembers was adjusted in
https://github.com/dlang/dmd/pull/6078.
All access checks will go away once the visibility changes have been
fully deprecated. So far those changes were adopted fairly slow (not
even phobos has fixed them all), hence we haven't yet switched over to
the new visibility semantics.

-Martin


Oh, now I remember. Yes, introspection works in "sudo" mode - all 
information is available to it, including what's private and what isn't 
:o). Thanks Martin for fielding this and other questions. -- Andrei




Re: Reminder - DConf 2017 is May 4-6 !!

2017-01-07 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 01/06/2017 08:06 PM, Stefan Koch wrote:

On Saturday, 7 January 2017 at 00:46:31 UTC, Walter Bright wrote:

It's 2017 already - sharpen your pencils and start on a proposal for a
presentation! Time is moving fast!


Thanks for the remainder.

I am still torn between talking about the past of building the new CTFE
engine or the future my plan for O(N log N) templates!


The new engine please. -- Andrei


Re: Vision document for H1 2017

2017-01-07 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 01/04/2017 11:43 PM, Basile B. wrote:

To simplify introspection with library traits that use the compiler
"__traits()" someone has to remove the restrictions related to
protection attributes. This is not a new topic. Without this, the new
library traits won't work well and people won't use them.


Is this formalized in bugzilla? -- Andrei


New (page-per-artifact) standard library doc examples are now editable and runnable

2017-01-07 Thread Andrei Alexandrescu via Digitalmars-d-announce
Following https://github.com/dlang/dlang.org/pull/1532, the new-style 
docs now also allow editing and running examples. Start at 
http://dlang.org/library-prerelease/ and go anywhere to check it out.


Thanks are due to Sönke Ludwig and Sebastian Wilzbach!


Andrei


Re: Vision document for H1 2017

2017-01-07 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 01/04/2017 08:06 PM, Dibyendu Majumdar wrote:

C++ integration has disappeared? Is this now "done"?


We have a student on that. I've added a line for that to the doc. -- Andrei


Vision document for H1 2017

2017-01-04 Thread Andrei Alexandrescu via Digitalmars-d-announce
We release a brief Vision document summarizing the main goals we plan to 
pursue in the coming six months. This half we are focusing on three 
things: safety, lifetime management, and static introspection.


https://wiki.dlang.org/Vision/2017H1


Andrei


Re: Google Summer of Code 2017

2016-12-27 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 12/26/16 6:25 PM, Craig Dillabaugh wrote:

I've now created the Google Summer of Code Idea's page for 2017.  Its
empty at the moment, awaiting all your wonderful ideas:

https://wiki.dlang.org/GSOC_2017_Ideas

You can edit the page directly, though I may edit any submitted ideas
for the sake of consistency, grammar, etc.

Also, feel free to use this forum posting to start discussion on any
ideas you may have for the upcoming year.

I hope to be posting my wrap-up on the very successful 2016 GSoC
campaign soon.  I am a bit slow ...

Happy Holidays to everyone.

Craig


Thanks for doing this again, Craig! FWIW this year we may receive more 
student attention because our scholarship students at University 
Politehnica Bucharest and their advisors will "advertise" the projects. 
So let's make sure we get a good lineup of ideas. -- Andrei


Re: Blog Post - profiling with perf and friends

2016-12-25 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 12/25/2016 02:16 PM, Martin Nowak wrote:

Just a few infos on using perf and related tools for profiling on linux.

https://code.dawg.eu/profiling-with-perf-and-friends.html


That's awesome and very easy to follow, reproduce, and tweak.

One thing that would be terrific (also in keep with Vladimir's work 
https://blog.thecybershadow.net/2015/05/05/is-d-slim-yet/ which btw does 
not seem to work anymore - clicking on the graph takes to the error page 
http://digger.k3.1azy.net/trend/) is having an automated tracker of 
build performance. The tracker would be easily accessible and would flag 
PRs that decrease compilation speed by more than a tolerance. One OS 
should be enough for now. We need a clean machine (not shared for many 
other tasks). The Foundation can provide a Linux machine in my basement. 
Looking at our A-Team Seb, Vladimir, Martin please let me know if this 
is something you'd pursue.


Two other things. One, can one aggregate outputs from several perf runs? 
The unittest builds are likely to exercise other corners of the 
compiler; they're one per module so they'd entail multiple perf runs.


Second, in my dreams we should have @benchmark unittests in phobos that 
are run and produce a nice tabular output, for tabulation and plotting. 
Such output would make it easy to track how performance of the standard 
library is evolving across releases.



Thanks,

Andrei



Re: New GDC binaries: 2.068.2, shared library support, multilib support & a new gdmd tool

2016-12-25 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 12/25/2016 02:41 PM, Johannes Pfau wrote:

Happy holidays everybody,

I'm happy to finally announce the release of new GDC binaries at
https://gdcproject.org/downloads . GDC is the GNU D Compiler, a D
compiler using GCC as the compiler backend.


Congratulations! We are very hopeful that all compiler will keep tightly 
together in 2017 and beyond, and it's clear you are taking good steps 
toward making that happen. -- Andrei


Re: Silicon Valley D Meetup - December 22, 2016 - "The Curse of Knowledge: Et tu, D?" by Adam Wilson

2016-12-24 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 12/24/16 2:30 AM, Ali Çehreli wrote:

On 12/15/2016 12:20 AM, Ali Çehreli wrote:


  https://www.meetup.com/D-Lang-Silicon-Valley/events/236253882/


The slides:
http://files.meetup.com/18234529/The%20Curse%20of%20Knowledge.pptx

The video: http://youtu.be/XjnBMfVTI0k

(There is no audio on the recording until 45:45.)


Looks like we have more of a curse of A/V setup :o). Walter's talk and 
now this. -- Andrei




Re: [your donation here]

2016-12-19 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 12/19/2016 09:26 PM, Joakim wrote:

On Monday, 19 December 2016 at 19:39:25 UTC, Andrei Alexandrescu wrote:

The D Language has had a great year! Among the many highlights, we are
very proud to offer scholarships to four exceptional graduate students
(https://dlang.org/blog/2016/12/05/the-d-language-foundations-scholarship-program/).
With your help, more great graduate students could pursue research in
Computer Science and Engineering.

[...]


Would be worthwhile to add a Bitcoin address too, lot of techies have it
and easy to use.


Thanks, I've opened a discussion internally. -- Andrei


[your donation here]

2016-12-19 Thread Andrei Alexandrescu via Digitalmars-d-announce
The D Language has had a great year! Among the many highlights, we are 
very proud to offer scholarships to four exceptional graduate students 
(https://dlang.org/blog/2016/12/05/the-d-language-foundations-scholarship-program/). 
With your help, more great graduate students could pursue research in 
Computer Science and Engineering.


Please consider making a personal donation, and also bring the word to 
the responsible people at your employer. We have no overheads and no 
conflict of interest because all of our officers are unpaid volunteers. 
So every $5 you donate go straight to one hour of scholarship! Use 
paypal safely and securely. We will provide you with a thank you letter 
that you can use for tax (and bragging) purposes. Many thanks to 
Sebastian Wilzbach who has put together this campaign.


https://dlang.org/donate.html


Thanks,

Andrei


Many documentation examples can now be run online

2016-12-19 Thread Andrei Alexandrescu via Digitalmars-d-announce
Take a look e.g. at 
https://dlang.org/phobos-prerelease/std_algorithm_iteration.html. 
Examples now have "Edit" and "Run" buttons that allow you to play with 
them online and see what they output. Changes for the ddox version 
forthcoming.


Related: https://github.com/dlang/dlang.org/pull/1297, 
https://issues.dlang.org/show_bug.cgi?id=16984, 
https://issues.dlang.org/show_bug.cgi?id=16985.


Many thanks to Sebastian Wilzbach who took this to completion, and to 
Damian Ziemba for working on the online compiler code!



Andrei


Re: LDC 1.1.0-beta6

2016-12-13 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 12/13/2016 02:37 PM, kinke wrote:

Hey all,

on behalf of the LDC team I am proud to announce the new 1.1.0-beta6
release!
It's based on the 2.071.2 frontend and standard library and supports
LLVM 3.5 up to current trunk (4.0).


This is awesome! Could you please tell what the expected lag time is 
between a dmd release and an ldc release? Also, obviously what we could 
do to improve that. Thanks! -- Andrei




Re: Mir Blog: Writing efficient numerical code in D

2016-12-12 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 12/12/16 4:58 PM, Relja Ljubobratovic wrote:

Hey guys,

We have just published another post on "Writing efficient numerical code
in D", to Mir's Blog[1]. In this post we are focusing on
mir.ndslice.algorithm usage in DCV[2], computer vision library that has
recently joined libmir organization. We've had great success in
optimizing DCV's algorithms mostly by replacing loop-style code with
mir.ndslice.algorithm multidimensional iteration utilities[3], and we
thought it was worth blogging about.

Any grammar (or any other type of) fix report is greatly appreciated!

Also, we'd like to ask Mike Parker to forward this to reddit if it's not
too much trouble? :) Maybe only wait few days so we could weed out some
mistakes from the text.

Cheers,
Relja

[1]
http://blog.mir.dlang.io/ndslice/algorithm/optimization/2016/12/12/writing-efficient-numerical-code.html

[2] https://github.com/libmir/dcv
[3] https://github.com/libmir/dcv/pull/58


This is awesome! Mike, could you please post to reddit about 11 hours 
from now if possible.


I'm about to fall asleep, but I made a quick pass through the piece. 
Here are a few nits:


* "In this post I’d like give" -> "This post gives"

* "module equipped with" -> "module that provides"

* "it’s usage" -> "its usage"

* "Note: It is assumed the reader is already somewhat familiar with 
ndslice package [1]." -> "This article assumes the reader has a cursory 
understanding of the ndslice package. If not, please consult this 
post/doc/webpage/etc before returning here."


* "What does it offer?" -> "What does mir.ndslice.algorithm offer?"

* "its integrated seamlessly" -> "it is integrated seamlessly"

* "by that allowing more natural flow of processing pipeline" -> "which 
makes for elegantly flowing processing pipelines"


* "One of key components to make code based" -> "One key component that 
makes code based"


* "LLVM based D compiler" -> "the LLVM based D compiler"

* "kernels you write" -> "computation kernels written by the end user"

* "else turned on" -> "turned on"

* ", by Johan Engelen" -> remove the comma

* "we’ve been actively refactoring" -> define the team; so far the 
article referred to the author as a single person


* "with mir.ndslice.algorithm equivalent" -> "with mir.ndslice.algorithm 
equivalents"


* align numbers in html tables to the right

* "As you can see, speedups" -> "Speedups"

* "as I’ll show you in this post" -> "as shown below"

* "take a look at PR" -> "take a look at the pull request"

* "Discalmer" -> "Disclaimer"

* "mind DCV project" -> "mind the DCV project"

* "showing power" -> "showing the power"

* "dive into implementation" -> "dive into the implementation"

* "without extensive optimization techniques applied" -> "without 
extensive optimizations"


* "In future we’ll focus" -> "A future post will focus"

* "first we’ll take a look" -> "first let's take a look"

* "basic principle how it can efficiently replace loop-based code" -> 
"basic principle of replacing loop-based code with pipelines efficiently"


* "… This code" -> "This code"

* "apply given kernel" -> "apply the given kernel"

* "To bring this example more down to earth" -> "To make the example 
more concrete"


* "As you can see, we are replacing" -> "The pipeline version replaces"

* "with few magic calls" -> "with a few magic calls"

* "And as you may have noticed, at" -> "At"

* "I get ~10x speedup" -> there's been a bunch of "we" and now getting 
back to "I" is surprising. You may want to make a pass making sure the 
use of person is consistent.


* "that variant written" -> "that the variant written"

* "syntax, and are" -> "syntax and are"

* "this is most basic binarization" -> "this is a most basic binarization"

* "Special part to care about, related to lockstep, is that byElement 
call on each input Slice" -> "The call to byElement inside lockstep is 
worth special attention"


* "We can notice right away there’s a change" -> "First off, there's a 
change"


* "requires this so" -> "assumes that is the case"

* "We can also notice byElement" -> "Notably, byElement"

* "examine performance differences" -> "compare the impact of these 
changes on performance"


* "On my machine" -> "On a Core i7 laptop with xyz GB or RAM and xyz 
other relevant parameters..."


* "result is following" -> "the results are as follows"

* "with very little effort using" -> "with very little effort by using"

* "and it’s submodules" -> "and its submodules"

* "coming for some numerical computing" -> "having an interest in 
numerical computing"


* "would have to be introduced to ndslice" -> "should take a close look 
at ndslice"


I suggest making two passes through the piece: (a) one pass should 
reduce fillers that are abundant ("as you can see", "as I'll show you", 
"as said in the docs"...) A few are fine (perhaps 2-3 in the whole 
article. Then (b) one pass looking for unified use of "I" (most likely: 
the author, use sparingly), "you" (the reader, use sparingly), and 

Re: DConf 2017: Bigger, Badder, and Berliner! Call for Submissions now open

2016-12-10 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 12/10/16 10:56 AM, Andrei Alexandrescu wrote:

On 11/25/16 9:10 PM, Andy Smith wrote:

I see this was pulled but no feedback as to whether it looked okay?
Doesn't seem to have made its way into the Dconf 2017 site. Seriously I
have no idea how my PR looks as I've not idea how to run ddoc.

All I know is that the 2017 site as it stands could use a bit of love
and I'm happy to help.

Let me know :-)

Cheers,

A.


Thanks, Andy.

Everyone - somebody really needs to take over dconf.org, if I don't
delegate some stuff I have so many jobs and my schedule is so
fragmented, I can't really appear to make progress on anything.


Forgot to mention - just uploaded the new logo, 
http://dconf.org/2017/index.html. Take a look! -- Andrei




Re: DConf 2017: Bigger, Badder, and Berliner! Call for Submissions now open

2016-12-10 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 11/25/16 9:10 PM, Andy Smith wrote:

I see this was pulled but no feedback as to whether it looked okay?
Doesn't seem to have made its way into the Dconf 2017 site. Seriously I
have no idea how my PR looks as I've not idea how to run ddoc.

All I know is that the 2017 site as it stands could use a bit of love
and I'm happy to help.

Let me know :-)

Cheers,

A.


Thanks, Andy.

Everyone - somebody really needs to take over dconf.org, if I don't 
delegate some stuff I have so many jobs and my schedule is so 
fragmented, I can't really appear to make progress on anything.



Andrei


Re: Getters/setters generator

2016-12-09 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 12/9/16 5:27 AM, Eugene Wissner wrote:

Hello,

we've just open sourced a small module ("accessors") that helps to
generate getters and setters automatically:
https://github.com/funkwerk/accessors
http://code.dlang.org/packages/accessors

It takes advantage of the UDAs and mixins. A simple example would be:

import accessors;

class WithAccessors
{
@Read @Write
private int num_;

mixin(GenerateFieldAccessors);
}

It would generate 2 methods "num": one to set num_ and one to get its
value. Of cause you can generate only @Read without @Write and vice
versa. There are some more features, you can find the full documentation
in the README.
"GenerateFieldAccessors" mixin should be added into each class/struct
that wants to use auto generated accessors.


Love it, and was toying with similar ideas too. One good extension is to 
add a predicate to the setter, which guards the assignment. -- Andrei


Re: Andrei on the new D Foundation Scholarships

2016-12-05 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 12/05/2016 08:36 AM, Mike Parker wrote:

After a two-week hiatus, the latest post at the blog takes the form of
an interview with Andrei regarding the new scholarships he announced a
couple weeks back. He talks about how the program came into existence,
how it works, and some of what he hopes to see come out of it. The
relevant links, as always follow. Given the nature of this particular
post, I opted to post it to /r/d_language rather than /r/programming.

Blog:
https://dlang.org/blog/2016/12/05/the-d-language-foundations-scholarship-program/


Reddit:
https://www.reddit.com/r/d_language/comments/5glwes/the_d_language_foundations_scholarship_program/


Thanks for the great writeup, Mike! -- Andrei



Re: DConf 2017: Bigger, Badder, and Berliner! Call for Submissions now open

2016-11-22 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 11/19/16 4:17 PM, Andy Smith wrote:


Until branding for the 2017 conf is sorted out/agreed would it be a big
deal to 'steal' the cool purple D rocket branding from the 2016 site?
(Changing the 6 to a 7 obviously). If you switch between the two pages (
2016 vs 2017 ). 2017 currently looks distinctly spartan :-(

http://dconf.org/2017

http://dconf.org/2016

Cheers,

A.


That would be great. Do you have time to volunteer a couple of PRs? -- 
Andrei




Re: Formal review of DIP1002

2016-11-18 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 11/18/16 12:10 PM, Andrei Alexandrescu wrote:

What could we have done in the particular case of DIP2002 to make things
better?


s/2002/1002/



Re: Formal review of DIP1002

2016-11-18 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 11/18/16 11:09 AM, pineapple wrote:

On Thursday, 17 November 2016 at 11:37:09 UTC, Dicebot wrote:

Disposition: REJECT. A proposal for a similar or identical feature
would need to be include qualitatively new motivation/evidence of
usefulness.

Please follow the link for the full review text / rationale:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md#review


There should be no need for me to repeat the arguments against the
DIP process already made by others.


You'd actually did us a huge favor if you did. I don't recall any
standing requests, so links to past discussions would be helpful. This
is a new process and Dicebot, myself, and Walter are very open to
suggestions on how to improve it.


I will be submitting no more DIPs or engaging in the process in any
way unless and until it is significantly changed.


What could we have done in the particular case of DIP2002 to make things 
better?



Thanks,

Andrei


Re: DIP document maintenance

2016-11-17 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 11/17/2016 10:43 AM, Dicebot wrote:

Yes. Assuming you do want multiple review iterations support, I can
imagine something like this:

- new "review candidate #" field is added to the header
- it is set to 0 on initial merge and to 1 after incorporating initial
NG feedback
- it also references specific DIP version hash matching time of
incrementing the version
- changes to DIP are made in a regular manner. When author is done, rc #
is incremented and hash gets updated
- included reviews refer to specific rc #

If that sounds good, I'll make a PR to update README and ping you from
there.


Yes, it does sound good. I think in general the "Information Requested" 
stage may contain one or more hefty reviews and also ask for arbitrarily 
complex information. So we need to allow submitters the opportunity to 
submit a distinct version of the same DIP with significant enhancements 
that is essentially a new document (with its own review!) save for the 
DIP number. Thanks! -- Andrei




Re: DIP document maintenance

2016-11-17 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 11/17/2016 09:16 AM, Dicebot wrote:

2) It is a regular update. In that case revision number is simply git
history. For example DIP1002 is currently at revision 7 (git log
--pretty=oneline DIPs/DIP1002.md | wc -l).

Same goes for update of reviews - everything is tracked in git history.
At any given point of time you simply throw away everything old and keep
only most recent versions.


OK, so we're just using git for versioning, which should work fine. The 
one potential issue I see with it is the version number is not 
indicative of how many review cycles have been passed. E.g. DIP1002 is 
already at revision 7, which is an irrelevant number to the casual 
reader. "What do you think of DIP2749?" "Which revision you mean?" "Well 
it's revision 38." "Would that be before or after the third review?" etc.


I'd like to have a simple tag a la DIP2749 v1 for the first review 
round, DIP2749 v2 for the second review round, and so on. So then people 
can refer to "DIP2749 v3" in casual conversation. Is this feasible?



Andrei



Re: Formal review of DIP1002

2016-11-17 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 11/17/2016 06:37 AM, Dicebot wrote:

Disposition: REJECT. A proposal for a similar or identical feature would
need to be include qualitatively new motivation/evidence of usefulness.

Please follow the link for the full review text / rationale:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md#review


Thanks Dicebot for carrying the process through. I think we need a 
versioning mechanism for DIPs. In the general case we'll have the 
disposition "Changes Requested", which will prompt the DIP authors to 
revise the DIP. The DIP will keep its number but will receive a new 
revision (either a newer commit or, more likely, an entirely new 
document). That revision will receive a new, separate review etc. -- Andrei


Re: Formal review of DIP1001

2016-11-17 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 11/17/2016 06:35 AM, Dicebot wrote:

Disposition: REJECT. A proposal for a similar or identical feature would
need to be include qualitatively new motivation/evidence of usefulness.

Please follow the link for the full review text / rationale:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1001.md#review


"to be include" -> "to include" (my bad, also propagated by copypasta in 
both responses). -- Andrei




Re: Formal review of DIP1001

2016-11-17 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 11/17/2016 06:35 AM, Dicebot wrote:

Disposition: REJECT. A proposal for a similar or identical feature would
need to be include qualitatively new motivation/evidence of usefulness.

Please follow the link for the full review text / rationale:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1001.md#review


"does nor argue" -> "does not argue" -- Andrei



Re: Boston D Language Meetup in Back Bay

2016-11-16 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 11/16/16 6:34 PM, Steven Schveighoffer wrote:

On 11/13/16 6:51 PM, Steven Schveighoffer wrote:

On 11/4/16 12:02 PM, Steven Schveighoffer wrote:

Just announced:
https://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/235353279/




We are going to try a freely available conference room to have a
presentation. No details on the presentation yet (I will figure that out
soon), and probably no streaming this time.


I got streaming to work. Will post a link later, in case anyone is
interested.


We should be online in some 23 minutes - the quality during the tests is 
great! -- Andrei


  1   2   3   4   5   6   7   >