## digitalmars.D - http://wiki.dlang.org/DIP25

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter and I have been working on revamping DIP25, which focuses on
tightening the screws of ref. This should then simplify DIP69 significantly.

Thanks,

Andrei

Dec 27 2014
"Peter Alexander" <peter.alexander.au gmail.com> writes:
On Sunday, 28 December 2014 at 03:09:20 UTC, Andrei Alexandrescu
wrote:

This seems like it may be painful (in terms of breaking existing
code):

"Member functions of structs must qualify this with inout if they
want to return a result by ref that won't outlive this."

This breaks all ranges that return ref front, no? (assuming they
aren't qualified inout, which appears to be the case in the
majority of ranges in std.algorithm/range).

Clarification: how does this DIP play with auto ref returns?
Infer non-ref if not qualified inout?

auto ref foo(ref int x) { return x; }  // non-ref due to lack of
inout on x?

Dec 28 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/28/14 2:13 AM, Peter Alexander wrote:
On Sunday, 28 December 2014 at 03:09:20 UTC, Andrei Alexandrescu wrote:

This seems like it may be painful (in terms of breaking existing code):

"Member functions of structs must qualify this with inout if they want
to return a result by ref that won't outlive this."

This breaks all ranges that return ref front, no? (assuming they aren't
qualified inout, which appears to be the case in the majority of ranges
in std.algorithm/range).

Very little breakage I can think of. Ranges usually don't own their payload.

Clarification: how does this DIP play with auto ref returns? Infer
non-ref if not qualified inout?

auto ref foo(ref int x) { return x; }  // non-ref due to lack of inout
on x?

"auto" has no meaning there. It does here:

auto ref foo(auto ref int x) { return x; }

This wouldn't compile anymore - inout is needed for x as well.

Andrei

Dec 28 2014
"Peter Alexander" <peter.alexander.au gmail.com> writes:
On Sunday, 28 December 2014 at 18:16:04 UTC, Andrei Alexandrescu
wrote:
Very little breakage I can think of. Ranges usually don't own

I'm thinking more about higher order ranges, e.g. take, filter,
cycle, retro; over a mutable range with ref front. Even if the
underlying range (e.g. an array) has the inout, the higher order
range will need the inout as well, so that it is propagated, no?

auto ref foo(ref int x) { return x; }  // non-ref due to lack
of inout
on x?

"auto" has no meaning there. It does here:

auto ref foo(auto ref int x) { return x; }

This wouldn't compile anymore - inout is needed for x as well.

Ah, yep. That's what I meant :-)  Thanks for the clarification.

Dec 28 2014
Walter Bright <newshound2 digitalmars.com> writes:
On 12/28/2014 12:04 PM, Peter Alexander wrote:
On Sunday, 28 December 2014 at 18:16:04 UTC, Andrei Alexandrescu wrote:
Very little breakage I can think of. Ranges usually don't own their payload.

I'm thinking more about higher order ranges, e.g. take, filter, cycle, retro;
over a mutable range with ref front. Even if the underlying range (e.g. an
array) has the inout, the higher order range will need the inout as well, so
that it is propagated, no?

inout is not transitive, so a ref on the container doesn't apply to a ref on
the
contents if there's another level of indirection in there.

Dec 28 2014
Walter Bright <newshound2 digitalmars.com> writes:
On 12/28/2014 1:33 PM, Walter Bright wrote:
On 12/28/2014 12:04 PM, Peter Alexander wrote:
On Sunday, 28 December 2014 at 18:16:04 UTC, Andrei Alexandrescu wrote:
Very little breakage I can think of. Ranges usually don't own their payload.

I'm thinking more about higher order ranges, e.g. take, filter, cycle, retro;
over a mutable range with ref front. Even if the underlying range (e.g. an
array) has the inout, the higher order range will need the inout as well, so
that it is propagated, no?

inout is not transitive, so a ref on the container doesn't apply to a ref on
the
contents if there's another level of indirection in there.

Also, inout on parameters will be inferred for templates, and most ranges are
templates.

Dec 28 2014
Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/28/14 4:33 PM, Walter Bright wrote:
On 12/28/2014 12:04 PM, Peter Alexander wrote:
On Sunday, 28 December 2014 at 18:16:04 UTC, Andrei Alexandrescu wrote:
Very little breakage I can think of. Ranges usually don't own their

I'm thinking more about higher order ranges, e.g. take, filter, cycle,
retro;
over a mutable range with ref front. Even if the underlying range
(e.g. an
array) has the inout, the higher order range will need the inout as
well, so
that it is propagated, no?

inout is not transitive, so a ref on the container doesn't apply to a
ref on the contents if there's another level of indirection in there.

I'm not sure what you mean by this, but inout as a type modifier is
definitely transitive.

-Steve

Dec 29 2014
Walter Bright <newshound2 digitalmars.com> writes:
On 12/29/2014 5:53 AM, Steven Schveighoffer wrote:
On 12/28/14 4:33 PM, Walter Bright wrote:
inout is not transitive, so a ref on the container doesn't apply to a
ref on the contents if there's another level of indirection in there.

I'm not sure what you mean by this, but inout as a type modifier is definitely
transitive.

As a type modifier, yes, it is transitive. As transferring lifetime to the
return value, it is not.

Dec 29 2014
Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/29/14 2:50 PM, Walter Bright wrote:
On 12/29/2014 5:53 AM, Steven Schveighoffer wrote:
On 12/28/14 4:33 PM, Walter Bright wrote:
inout is not transitive, so a ref on the container doesn't apply to a
ref on the contents if there's another level of indirection in there.

I'm not sure what you mean by this, but inout as a type modifier is
definitely
transitive.

As a type modifier, yes, it is transitive. As transferring lifetime to
the return value, it is not.

I strongly suggest not to use inout to mean this. This idea would be a
disaster.

-Steve

Dec 29 2014
On Monday, 29 December 2014 at 20:26:27 UTC, Steven Schveighoffer
wrote:
On 12/29/14 2:50 PM, Walter Bright wrote:
On 12/29/2014 5:53 AM, Steven Schveighoffer wrote:
On 12/28/14 4:33 PM, Walter Bright wrote:
inout is not transitive, so a ref on the container doesn't
apply to a
ref on the contents if there's another level of indirection
in there.

I'm not sure what you mean by this, but inout as a type
modifier is
definitely
transitive.

As a type modifier, yes, it is transitive. As transferring
the return value, it is not.

I strongly suggest not to use inout to mean this. This idea
would be a disaster.

-Steve

On the other hand, inout IS a disaster, so why not ?

Jan 05 2015
Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/5/15 8:06 AM, deadalnix wrote:
On Monday, 29 December 2014 at 20:26:27 UTC, Steven Schveighoffer wrote:
On 12/29/14 2:50 PM, Walter Bright wrote:
On 12/29/2014 5:53 AM, Steven Schveighoffer wrote:
On 12/28/14 4:33 PM, Walter Bright wrote:
inout is not transitive, so a ref on the container doesn't apply to a
ref on the contents if there's another level of indirection in there.

I'm not sure what you mean by this, but inout as a type modifier is
definitely
transitive.

As a type modifier, yes, it is transitive. As transferring lifetime to
the return value, it is not.

I strongly suggest not to use inout to mean this. This idea would be a
disaster.

On the other hand, inout IS a disaster, so why not ?

I strongly disagree :) inout enables so many things that just aren't
possible otherwise.

Most recent example:
https://github.com/D-Programming-Language/druntime/pull/1079

inout only gets confusing when you start using inout delegates.

-Steve

Jan 05 2015
"Meta" <jared771 gmail.com> writes:
On Monday, 5 January 2015 at 14:00:13 UTC, Steven Schveighoffer
wrote:
On 1/5/15 8:06 AM, deadalnix wrote:
On Monday, 29 December 2014 at 20:26:27 UTC, Steven
Schveighoffer wrote:
On 12/29/14 2:50 PM, Walter Bright wrote:
On 12/29/2014 5:53 AM, Steven Schveighoffer wrote:
On 12/28/14 4:33 PM, Walter Bright wrote:
inout is not transitive, so a ref on the container doesn't
apply to a
ref on the contents if there's another level of
indirection in there.

I'm not sure what you mean by this, but inout as a type
modifier is
definitely
transitive.

As a type modifier, yes, it is transitive. As transferring
the return value, it is not.

I strongly suggest not to use inout to mean this. This idea
would be a
disaster.

On the other hand, inout IS a disaster, so why not ?

I strongly disagree :) inout enables so many things that just
aren't possible otherwise.

Most recent example:
https://github.com/D-Programming-Language/druntime/pull/1079

inout only gets confusing when you start using inout delegates.

-Steve

IMO, inout (and const/immutable to a degree) is a failure for use
with class/struct methods. This became clear to me when trying to
use it for the toString implementation of Nullable.

Jan 05 2015
Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/5/15 10:05 AM, Meta wrote:

IMO, inout (and const/immutable to a degree) is a failure for use with
class/struct methods. This became clear to me when trying to use it for
the toString implementation of Nullable.

You'd have to be more specific for me to understand your point. inout
was specifically designed for one-implementation accessors for members
of classes/structs.

-Steve

Jan 05 2015
"Meta" <jared771 gmail.com> writes:
On Monday, 5 January 2015 at 19:21:38 UTC, Steven Schveighoffer
wrote:
On 1/5/15 10:05 AM, Meta wrote:

IMO, inout (and const/immutable to a degree) is a failure for
use with
class/struct methods. This became clear to me when trying to
use it for
the toString implementation of Nullable.

You'd have to be more specific for me to understand your point.
inout was specifically designed for one-implementation
accessors for members of classes/structs.

-Steve

I cannot remember what the exact issue is now as it was awhile
ago, but it had to do with a creating inout/const/immutable
Nullables. When doing something such as Nullable!TestStruct ts;
writeln(ts), the check inside Nullable.get is triggered instead
of calling toString, because toString is not marked as
inout/const/immutable. The only solution seems to have a separate
version of toString for inout, const, and immutable. It seems
that pretty much defeats the point of having inout in the first
place.

Jan 08 2015
Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/8/15 4:04 PM, Meta wrote:
On Monday, 5 January 2015 at 19:21:38 UTC, Steven Schveighoffer wrote:
On 1/5/15 10:05 AM, Meta wrote:

IMO, inout (and const/immutable to a degree) is a failure for use with
class/struct methods. This became clear to me when trying to use it for
the toString implementation of Nullable.

You'd have to be more specific for me to understand your point. inout
was specifically designed for one-implementation accessors for members
of classes/structs.

-Steve

I cannot remember what the exact issue is now as it was awhile ago, but
it had to do with a creating inout/const/immutable Nullables. When doing
something such as Nullable!TestStruct ts; writeln(ts), the check
inside Nullable.get is triggered instead of calling toString, because
toString is not marked as inout/const/immutable. The only solution seems
to have a separate version of toString for inout, const, and immutable.
It seems that pretty much defeats the point of having inout in the first
place.

That sounds like the delegate issue. If you are not dealing with
delegates, then it works well.

Working with inout delegates gets tricky, because it's impossible to
refer to inout the type constructor as a parameter to a function without
the compiler thinking this is a new invocation of inout.

Timon Gehr had ideas on how to fix it, but I don't think anything ever
came of it.

-Steve

Jan 08 2015
On Monday, 5 January 2015 at 14:00:13 UTC, Steven Schveighoffer
wrote:
I strongly disagree :) inout enables so many things that just
aren't possible otherwise.

Most recent example:
https://github.com/D-Programming-Language/druntime/pull/1079

inout only gets confusing when you start using inout delegates.

-Steve

You are arguing that inout is useful. That simply makes it a
useful disaster :)

Jan 05 2015
Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/5/15 11:51 AM, deadalnix wrote:
On Monday, 5 January 2015 at 14:00:13 UTC, Steven Schveighoffer wrote:
I strongly disagree :) inout enables so many things that just aren't
possible otherwise.

Most recent example:
https://github.com/D-Programming-Language/druntime/pull/1079

inout only gets confusing when you start using inout delegates.

You are arguing that inout is useful. That simply makes it a useful
disaster :)

I guess you and me have different ideas of what a disaster is :)

-Steve

Jan 05 2015
On Monday, 5 January 2015 at 19:18:34 UTC, Steven Schveighoffer
wrote:
On 1/5/15 11:51 AM, deadalnix wrote:
On Monday, 5 January 2015 at 14:00:13 UTC, Steven
Schveighoffer wrote:
I strongly disagree :) inout enables so many things that just
aren't
possible otherwise.

Most recent example:
https://github.com/D-Programming-Language/druntime/pull/1079

inout only gets confusing when you start using inout
delegates.

You are arguing that inout is useful. That simply makes it a
useful
disaster :)

I guess you and me have different ideas of what a disaster is :)

-Steve

Nop. Great usefulness makes it almost impossible to get rid of in
its current form.

Jan 05 2015
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/28/14 12:04 PM, Peter Alexander wrote:
On Sunday, 28 December 2014 at 18:16:04 UTC, Andrei Alexandrescu wrote:
Very little breakage I can think of. Ranges usually don't own their

I'm thinking more about higher order ranges, e.g. take, filter, cycle,
retro; over a mutable range with ref front. Even if the underlying range
(e.g. an array) has the inout, the higher order range will need the
inout as well, so that it is propagated, no?

Not even those for the most part. The archetypal higher order range:

struct Wrapper(R)
{
ref ElementType!R front() {
}
...
}

If R.front() returns a ref T, that's all Wrapper needs to know - the
call just works. That would be the case if e.g. R is T[].

If R.front() is inout-qualified, indeed Wrapper needs to propagate that.
In this case, however, deduction can take care of it; Walter ensures me
that deduction of inout is cheap and relatively easy. I need to add a
section on it to the DIP.

For non-templates, inout would need to be added if a range that owns its
elements is to be wrapped. But generally ranges don't own stuff (i.e.
they can disappear and stuff is still there). Containers own stuff.

Andrei

Dec 28 2014
Walter Bright <newshound2 digitalmars.com> writes:
On 12/28/2014 6:29 PM, Andrei Alexandrescu wrote:
If R.front() is inout-qualified, indeed Wrapper needs to propagate that. In
this
case, however, deduction can take care of it; Walter ensures me that deduction
of inout is cheap and relatively easy. I need to add a section on it to the
DIP.

Here's how the deduction works. I presume the existence of a check to see if a
ref parameter is being returned by ref. If deduction is not being done, an
error
message is issued:

error: 'ref' parameter 'x' is being turned by ref, needs to be 'inout ref'

If deduction is being done, the error message is not issued, but the parameter
is marked as 'inout'.

Dec 28 2014
"Meta" <jared771 gmail.com> writes:
On Sunday, 28 December 2014 at 18:16:04 UTC, Andrei Alexandrescu
wrote:
"auto" has no meaning there. It does here:

auto ref foo(auto ref int x) { return x; }

This wouldn't compile anymore - inout is needed for x as well.

So are you saying that such code will require the following if
this DIP is implemented?

auto ref inout foo(auto ref inout(int) x) { return x; }

The idea is sound but that will be incredibly tedious to type
out. I know that Walter wants to infer inout for templates (a
good idea), but at some point or another somebody is going to
have to type that out for a regular function. Since scope is up
in the air right now, could it be redefined to mean auto ref
inout? It's a bit humourous; in would then mean const auto
ref inout.

Also, I guess this DIP implies that auto ref should work for
non-templated functions as well. That seems pretty good, but the
rvalue ref problem still hasn't been solved, and it's hard to say
whether DIP25 would help or hurt prospects for that.

Dec 28 2014
Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 28/12/14 04:09, Andrei Alexandrescu via Digitalmars-d wrote:
Walter and I have been working on revamping DIP25, which focuses on tightening
the screws of ref. This should then simplify DIP69 significantly.

How will that interact with designs like the singleton used in e.g.
std.random.rndGen:

property ref Random rndGen()  safe
{
import std.algorithm : map, repeat;

static Random result;
static bool initialized;
if (!initialized)
{
static if(isSeedable!(Random, typeof(map!((a) =>
unpredictableSeed)(repeat(0)))))
result.seed(map!((a) => unpredictableSeed)(repeat(0)));
else
result = Random(unpredictableSeed);
initialized = true;
}
return result;
}

... will it be as simple as adding an 'inout' qualifier to the method and/or
return type?  In any case I think it's a use-case worth adding to the example
list.

Dec 28 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/28/14 4:23 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
On 28/12/14 04:09, Andrei Alexandrescu via Digitalmars-d wrote:
Walter and I have been working on revamping DIP25, which focuses on
tightening
the screws of ref. This should then simplify DIP69 significantly.

How will that interact with designs like the singleton used in e.g.
std.random.rndGen:

property ref Random rndGen()  safe
{
import std.algorithm : map, repeat;

static Random result;
...
return result;
}

... will it be as simple as adding an 'inout' qualifier to the method
and/or return type?  In any case I think it's a use-case worth adding to
the example list.

No need to add anything here because returning a static is still fine.
-- Andrei

Dec 28 2014
Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 28/12/14 13:23, Joseph Rushton Wakeling via Digitalmars-d wrote:
... will it be as simple as adding an 'inout' qualifier to the method and/or
return type?  In any case I think it's a use-case worth adding to the example
list.

Ack, I missed it hidden away in the second-to-last example (the one at the end
of the 'Enhancing inout' section), where there's a static int b that is
returned
via ref, with no qualifiers required.  Still think it might be worth
highlighting separately how this DIP works with that singleton pattern.

Dec 28 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/28/14 4:32 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
On 28/12/14 13:23, Joseph Rushton Wakeling via Digitalmars-d wrote:
... will it be as simple as adding an 'inout' qualifier to the method
and/or
return type?  In any case I think it's a use-case worth adding to the
example list.

Ack, I missed it hidden away in the second-to-last example (the one at
the end of the 'Enhancing inout' section), where there's a static int b
that is returned via ref, with no qualifiers required.  Still think it
might be worth highlighting separately how this DIP works with that
singleton pattern.

Got it - could you please add what would be a satisfactory 'splanation?
Thanks! -- Andrei

Dec 28 2014
"Brad Anderson" <eco gnuk.net> writes:
On Sunday, 28 December 2014 at 03:09:20 UTC, Andrei Alexandrescu
wrote:
Walter and I have been working on revamping DIP25, which
focuses on tightening the screws of ref. This should then
simplify DIP69 significantly.

Thanks,

Andrei

I like the simplicity of it. It's a lot easier to understand than
the previous version. The breaking change is easy to identify and
fix and could actually reveal bugs.

+1

I still have to read through DIP 69 to see how this works with
that but I think this DIP would be a good addition on its own.

Dec 28 2014
Walter Bright <newshound2 digitalmars.com> writes:
On 12/28/2014 12:45 PM, Brad Anderson wrote:
On Sunday, 28 December 2014 at 03:09:20 UTC, Andrei Alexandrescu
wrote:
Walter and I have been working on revamping DIP25, which focuses on tightening
the screws of ref. This should then simplify DIP69 significantly.

Thanks,

Andrei

I like the simplicity of it. It's a lot easier to understand than
the previous version. The breaking change is easy to identify and
fix and could actually reveal bugs.

+1

I still have to read through DIP 69 to see how this works with
that but I think this DIP would be a good addition on its own.

Although I believe DIP69 is technically sound, it was abundantly clear from the
thread about it that almost nobody understood it. It was too complicated and
unintuitive. Andrei convinced me we had to go back to the drawing board.

DIP25 still needs to address things like overloading and inheritance, but I
think we can just swipe that from DIP69.

Dec 28 2014
"Joseph Cassman" <jc7919 outlook.com> writes:
On Sunday, 28 December 2014 at 03:09:20 UTC, Andrei Alexandrescu
wrote:
Walter and I have been working on revamping DIP25, which
focuses on tightening the screws of ref. This should then
simplify DIP69 significantly.

Thanks,

Andrei

I tried to understand the previous DIP but it was difficult. I
like how this new version explains what is being added and why.
The examples really help. I still need some time to understand
all the ins and outs of the concept but it has a nice ring of
clarity.

Nice work and thanks!

Joseph

Dec 28 2014
Walter Bright <newshound2 digitalmars.com> writes:
On 12/28/2014 5:57 PM, Joseph Cassman wrote:
I tried to understand the previous DIP but it was difficult. I like how this
new
version explains what is being added and why. The examples really help. I still
need some time to understand all the ins and outs of the concept but it has a
nice ring of clarity.

Phew!

Nice work and thanks!

Thank you.

Dec 28 2014
Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 28 December 2014 at 13:09, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
Walter and I have been working on revamping DIP25, which focuses on
tightening the screws of ref. This should then simplify DIP69 significantly.

Thanks,

Andrei

I could generally understand the intent, but I don't really understand
the connection between ref and inout.
They seem like unrelated things. I feel like conflating them could
only lead to unexpected problem cases when the concepts coincide
naturally, but the intent wasn't this assigned special case.
I wonder if we're just narrowing the window of edge cases, and
possibly into a slightly more awkward position for later fixes?

I'd like to see 'ref inout(int)' rather than 'ref inout int', to make
inout look like the type modifier that it is, rather than a storage
class, which it isn't.
That distinction made me start second-guessing my assumptions
throughout, and reduced my confidence in my understanding of the
proposal.

I'd also like to know how this will help DIP69? I can't imagine how
this could help DIP69 address the basic problems I was concerned with
(ie, distilling towards; 'storage class' is practically a bad design
for D, and my numerous rants and walls of text that follow).

Dec 28 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/28/14 7:40 PM, Manu via Digitalmars-d wrote:
On 28 December 2014 at 13:09, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
Walter and I have been working on revamping DIP25, which focuses on
tightening the screws of ref. This should then simplify DIP69 significantly.

Thanks,

Andrei

I could generally understand the intent, but I don't really understand
the connection between ref and inout.
They seem like unrelated things. I feel like conflating them could
only lead to unexpected problem cases when the concepts coincide
naturally, but the intent wasn't this assigned special case.
I wonder if we're just narrowing the window of edge cases, and
possibly into a slightly more awkward position for later fixes?

Walter's reasoning was: we have inout for propagating qualifiers from a
parameter ("this" is also a parameter) to the output, so we can use it
for propagating aliasing information as well.

One idea we discussed was to use "return" like this:

ref int fun(return ref int x); // may return x

Walter didn't like it. I'm somewhat neutral.

Any examples of cases when having inout do both would cause trouble?

I'd like to see 'ref inout(int)' rather than 'ref inout int', to make
inout look like the type modifier that it is, rather than a storage
class, which it isn't.
That distinction made me start second-guessing my assumptions
throughout, and reduced my confidence in my understanding of the
proposal.

When applied to a parameter, the parens are redundant.

I'd also like to know how this will help DIP69?

Just takes the entire ref handling out of the equation.

I can't imagine how
this could help DIP69 address the basic problems I was concerned with
(ie, distilling towards; 'storage class' is practically a bad design
for D, and my numerous rants and walls of text that follow).

I did want to say something about this. I've given a close read to the
"Lost a new commercial user this week" thread, through and through. It
seems I've identified a problem that belongs to us. ("Us" is a vacuous
term meaning "the leaders of the D community").

My initial read of your complaint went like this: it's about Windows (I
don't even have an installation), it's about vibe.d (haven't used it
yet), and it's also discussing documentation (which is something we can
indeed improve and I know how to). So a large part of the problem wasn't
even mine to work on.

Others harbored similar perceptions. The corollary has been that
essentially you're asking them to stop working on D aspects they do care
about and start working on D aspects you and others care about - all on
their free time.

Then I figured we must take ownership of D issues. Your initial post was
pure and simple user feedback - a knowledgeable and well-informed and
well-meaning user but nevertheless a user who is not quite willing to
roll sleeves up and proceed with adding work. If we consider ourselves a
free-wheeling grassroots tribe, best we can do invite you to do the work
and review and merge it in (or snicker at you if you're not up for it).
If, on the other hand, we want to be a real organization, we must take
the feedback and own it.

A simple simile: say you mention to the manager of a grocery store that
they should have more organic fruit, and mention anecdotes of potential
customers shunning the store because it doesn't. If the store is a
cooperative of folks selling stuff they grow on their own, the manager
might invite you to join in with your produce. If, on the other hand,
the store is an established supermarket, they'd do good to take your
suggestion seriously.

We're in the "cooperative" stage of D, and we need to move toward the
"established organization" stage. We should start transitioning to that
next year; part of it is I plan to look seriously at the non-profit
organization angle.

There is a rub though. Not only you're telling what we'd need to do to
be more successful, you're also telling us how to do it. Please don't.
We are not adding type qualifiers to D if we can avoid it, and generally
we want to achieve what we need to achieve with minimum aggravation.
Instead please focus on what you're trying to accomplish, not on whether
an artifact is a type qualifier or a storage class. Thanks.

Andrei

Dec 28 2014
Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 12/29/14, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
We're in the "cooperative" stage of D, and we need to move toward the
"established organization" stage.

Unrelated to this grander idea I really liked the recent Rust blog post:
http://discuss.rust-lang.org/t/a-tale-of-twos-complement/1062

We could consider writing these styles of posts for major changes
(like DIP25). We already have the changelog that documents everything
/after/ a release, but having a page where we announce upcoming
changes for the general population to read would be nice.

Once we agree on all aspects on DIP25, perhaps we could write a page
about it and put it up on dlang.org/news.html or somewhere. What do
you think?

Dec 29 2014
"John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 29 December 2014 at 04:13:18 UTC, Andrei Alexandrescu
wrote:
There is a rub though. Not only you're telling what we'd need
to do to be more successful, you're also telling us how to do
it. Please don't. We are not adding type qualifiers to D if we
can avoid it, and generally we want to achieve what we need to
achieve with minimum aggravation. Instead please focus on what
you're trying to accomplish, not on whether an artifact is a
type qualifier or a storage class. Thanks.

Andrei

But (one of) his point(s) is that the choice between type
qualifier and storage class directly impacts his work. Why
shouldn't a user express such a point?

Dec 29 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/29/14 2:58 AM, John Colvin wrote:
On Monday, 29 December 2014 at 04:13:18 UTC, Andrei Alexandrescu wrote:
There is a rub though. Not only you're telling what we'd need to do to
be more successful, you're also telling us how to do it. Please don't.
We are not adding type qualifiers to D if we can avoid it, and
generally we want to achieve what we need to achieve with minimum
aggravation. Instead please focus on what you're trying to accomplish,
not on whether an artifact is a type qualifier or a storage class.
Thanks.

Andrei

But (one of) his point(s) is that the choice between type qualifier and
storage class directly impacts his work. Why shouldn't a user express
such a point?

Making that point is fine so long as the costs are discussed alongside
with the applicability to one particular task. -- Andrei

Dec 29 2014
Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 30 December 2014 at 01:52, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On 12/29/14 2:58 AM, John Colvin wrote:
On Monday, 29 December 2014 at 04:13:18 UTC, Andrei Alexandrescu wrote:
There is a rub though. Not only you're telling what we'd need to do to
be more successful, you're also telling us how to do it. Please don't.
We are not adding type qualifiers to D if we can avoid it, and
generally we want to achieve what we need to achieve with minimum
aggravation. Instead please focus on what you're trying to accomplish,
not on whether an artifact is a type qualifier or a storage class.
Thanks.

Andrei

But (one of) his point(s) is that the choice between type qualifier and
storage class directly impacts his work. Why shouldn't a user express
such a point?

Making that point is fine so long as the costs are discussed alongside with
the applicability to one particular task. -- Andrei

It's not one particular task. It is the common theme for almost all
ref related problems (other than rvalue->ref, which is just
arbitrarily rejected currently).
I'm trying to raise that topic for discussions, but nobody wants to
talk about it, and would rather focus on patches instead.
I don't know exactly where ref as type constructor would lead. Sure,
it would be complex no doubt, but not necessarily any more or less
complex than the awkward network of edge cases we're trying to deal
with in these discussions currently.
My feeling is, all these discussions are essentially arguing an
*extremely* complex suite of language patches. I'm interested in
considering the root problem for contrast... I think we'd find
ourselves in a position with a lot less edges as result.

Dec 29 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/29/14 5:02 PM, Manu via Digitalmars-d wrote:
On 30 December 2014 at 01:52, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On 12/29/14 2:58 AM, John Colvin wrote:
On Monday, 29 December 2014 at 04:13:18 UTC, Andrei Alexandrescu wrote:
There is a rub though. Not only you're telling what we'd need to do to
be more successful, you're also telling us how to do it. Please don't.
We are not adding type qualifiers to D if we can avoid it, and
generally we want to achieve what we need to achieve with minimum
aggravation. Instead please focus on what you're trying to accomplish,
not on whether an artifact is a type qualifier or a storage class.
Thanks.

Andrei

But (one of) his point(s) is that the choice between type qualifier and
storage class directly impacts his work. Why shouldn't a user express
such a point?

Making that point is fine so long as the costs are discussed alongside with
the applicability to one particular task. -- Andrei

It's not one particular task. It is the common theme for almost all
ref related problems (other than rvalue->ref, which is just
arbitrarily rejected currently).

Not arbitrary at all. The problem with binding rvalues to ref is that
subsequently the ref may escape the scope. DIP25 would not have been
possible if rvalues bound to ref.

I'm trying to raise that topic for discussions, but nobody wants to
talk about it, and would rather focus on patches instead.
I don't know exactly where ref as type constructor would lead.

That would imply you'd have more restraint in pushing it.

Sure,
it would be complex no doubt, but not necessarily any more or less
complex than the awkward network of edge cases we're trying to deal
with in these discussions currently.
My feeling is, all these discussions are essentially arguing an
*extremely* complex suite of language patches. I'm interested in
considering the root problem for contrast... I think we'd find
ourselves in a position with a lot less edges as result.

Andrei

Dec 30 2014
Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 31 December 2014 at 08:26, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On 12/29/14 5:02 PM, Manu via Digitalmars-d wrote:
On 30 December 2014 at 01:52, Andrei Alexandrescu via Digitalmars-d

<digitalmars-d puremagic.com> wrote:
On 12/29/14 2:58 AM, John Colvin wrote:
On Monday, 29 December 2014 at 04:13:18 UTC, Andrei Alexandrescu wrote:
There is a rub though. Not only you're telling what we'd need to do to
be more successful, you're also telling us how to do it. Please don't.
We are not adding type qualifiers to D if we can avoid it, and
generally we want to achieve what we need to achieve with minimum
aggravation. Instead please focus on what you're trying to accomplish,
not on whether an artifact is a type qualifier or a storage class.
Thanks.

Andrei

But (one of) his point(s) is that the choice between type qualifier and
storage class directly impacts his work. Why shouldn't a user express
such a point?

Making that point is fine so long as the costs are discussed alongside
with
the applicability to one particular task. -- Andrei

It's not one particular task. It is the common theme for almost all
ref related problems (other than rvalue->ref, which is just
arbitrarily rejected currently).

Not arbitrary at all. The problem with binding rvalues to ref is that
subsequently the ref may escape the scope. DIP25 would not have been
possible if rvalues bound to ref.

However this code is perfectly legal:

void mayEscape(ref int x); // <-- may escape this ref arg

void t()
{
int onStack = 1;
mayEscape(onStack); // <- perfectly legal, and equally unsafe
}

While that code is legal, the rejection of rvalue->ref is absolutely arbitrary.
The 'workaround' for not allowing rvalue->ref is to simply assign it
to a stack local with a stupid name (eg: t1, t2, etc) on the preceding
line.
That workaround appears in *every* instance that rvalue->ref would be
used, making code messy and more difficult to maintain.

Obviously, I'm all for scope, and lifetimes and all that to make this
stuff properly safe. But the current situation is that we are
inconvenienced by an arbitrary decision.

I'm trying to raise that topic for discussions, but nobody wants to
talk about it, and would rather focus on patches instead.
I don't know exactly where ref as type constructor would lead.

That would imply you'd have more restraint in pushing it.

Why? I think there's a serious danger here.
Precedent would lead to me to fear that the sort of reasoning that
lead to 'auto ref' may prevail here again.

Sure,
it would be complex no doubt, but not necessarily any more or less
complex than the awkward network of edge cases we're trying to deal
with in these discussions currently.
My feeling is, all these discussions are essentially arguing an
*extremely* complex suite of language patches. I'm interested in
considering the root problem for contrast... I think we'd find
ourselves in a position with a lot less edges as result.

In what way?
I don't see why exploring a more fundamental solution is absolutely
off the table.

Dec 30 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/30/14 7:32 PM, Manu via Digitalmars-d wrote:
void mayEscape(ref int x); // <-- may escape this ref arg

void t()
{
int onStack = 1;
mayEscape(onStack); // <- perfectly legal, and equally unsafe
}

DIP25 puts this code in illegality. I don't think the proposal has been
explicit about that, will fix. Thanks! -- Andrei

Dec 30 2014
Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 12/31/14, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On 12/30/14 7:32 PM, Manu via Digitalmars-d wrote:
void mayEscape(ref int x); // <-- may escape this ref arg

void t()
{
int onStack = 1;
mayEscape(onStack); // <- perfectly legal, and equally unsafe
}

DIP25 puts this code in illegality. I don't think the proposal has been
explicit about that, will fix. Thanks! -- Andrei

Wait, what? Passing stack variables by ref will be disallowed?

Dec 31 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdan.org> writes:
Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> wrote:
On 12/31/14, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On 12/30/14 7:32 PM, Manu via Digitalmars-d wrote:
void mayEscape(ref int x); // <-- may escape this ref arg

void t()
{
int onStack = 1;
mayEscape(onStack); // <- perfectly legal, and equally unsafe
}

DIP25 puts this code in illegality. I don't think the proposal has been
explicit about that, will fix. Thanks! -- Andrei

Wait, what? Passing stack variables by ref will be disallowed?

Only to functions that return ref.

Dec 31 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/30/14 7:32 PM, Manu via Digitalmars-d wrote:
While that code is legal, the rejection of rvalue->ref is absolutely arbitrary.
The 'workaround' for not allowing rvalue->ref is to simply assign it
to a stack local with a stupid name (eg: t1, t2, etc) on the preceding
line.
That workaround appears in*every*  instance that rvalue->ref would be
used, making code messy and more difficult to maintain.

The alternate hypothesis is "ref" is being misused. "ref" is for
propagating changes into the arguments. It should be rare that code does
not actually care for that. Unlike in C++, ref is seldom needed for
optimizing copies away. -- Andrei

Dec 30 2014
ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 30 Dec 2014 21:28:32 -0800
Andrei Alexandrescu via Digitalmars-d <digitalmars-d puremagic.com>
wrote:

The alternate hypothesis is "ref" is being misused. "ref" is for=20
propagating changes into the arguments. It should be rare that code does=

=20
not actually care for that. Unlike in C++, ref is seldom needed for=20
optimizing copies away. -- Andrei

slightly derailing comment: the small annoyance of ref is that it
hides the fact that i'm passing argument by reference. i still can't
fully convince myself that i should use ref instead of explicit
pointer, 'cause:

void foo (ref int a);
void bar (int a);

// and the following calls looks all the same T_T
int a;
foo(a);
bar(a);

but:

void foo (int* a);
void bar (int a);

// wow, we don't even need to look at the signatures to find
// that foo wants a reference and that it therefore can
// modify a!
int a;
foo(&a);
bar(a);

another "cosmetic issue" that bugs me alot.

p.s. and with pointers it's easy to write something like this:

auto parseNumber (string s, bool* error=3Dnull);

yes, i know about exceptions... which blocks  nogc. not yummy.

Dec 30 2014
"Tobias Pankrath" <tobias pankrath.net> writes:
On Wednesday, 31 December 2014 at 06:04:41 UTC, ketmar via
Digitalmars-d wrote:
void foo (ref int a);
void bar (int a);

// and the following calls looks all the same T_T
int a;
foo(a);
bar(a);

but:

void foo (int* a);
void bar (int a);

// wow, we don't even need to look at the signatures to find
// that foo wants a reference and that it therefore can
// modify a!
int a;
foo(&a);
bar(a);

To require ref at the callside was proposed long ago. Dunno if
this would
make Manu's task harder. I agree, that this might have been
better in
the long run.

another "cosmetic issue" that bugs me alot.

p.s. and with pointers it's easy to write something like this:

auto parseNumber (string s, bool* error=null);

yes, i know about exceptions... which blocks  nogc. not yummy.

You could preallocate the exception or use an out parameter.

Dec 31 2014
ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 31 Dec 2014 09:40:17 +0000
Tobias Pankrath via Digitalmars-d <digitalmars-d puremagic.com> wrote:

another "cosmetic issue" that bugs me alot.

p.s. and with pointers it's easy to write something like this:

auto parseNumber (string s, bool* error=3Dnull);

yes, i know about exceptions... which blocks  nogc. not yummy.

=20
You could preallocate the exception or use an out parameter.

i can do alot of things here... and something is not possible with
ref. this will not work:

auto parseNumber (string s, ref bool error=3Dnull);

ther is no way to point ref to dummy temp by default, sure, i can write
two functions:

auto parseNumber (string s, out bool error);
auto parseNumber (string s) { bool dummy; return parseNumber(s, dummy); }

see how it's turning to messy code with copypasta? the thing is that
ref params can't be ommited by specifying null here, and there is
no dummy placeholder for refs. the same is true for outs, of
course.

and preallocating exception is loosing valuable information about the
place where that exception was thrown. or i have to write a module
which emulates new for exception objects and don't forget to check if
it is "D exception" or "my exception" in catch block, so i can
manually release my exceptions. ah, i'd better go with my ugly pointers.

Dec 31 2014
Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 31 December 2014 at 15:28, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On 12/30/14 7:32 PM, Manu via Digitalmars-d wrote:
While that code is legal, the rejection of rvalue->ref is absolutely
arbitrary.
The 'workaround' for not allowing rvalue->ref is to simply assign it
to a stack local with a stupid name (eg: t1, t2, etc) on the preceding
line.
That workaround appears in*every*  instance that rvalue->ref would be
used, making code messy and more difficult to maintain.

The alternate hypothesis is "ref" is being misused. "ref" is for propagating
changes into the arguments. It should be rare that code does not actually
care for that. Unlike in C++, ref is seldom needed for optimizing copies
away. -- Andrei

Exactly like C++, ref it equally needed for optimising copies away. If
you use separate compilation, or binary libs (normal practise outside
OSS), then you still need it.
Also, when binding to external code; C++ api's have ref, so D bindings
have ref. I interact with C code more than I interact with other D
code.

Your view on ref only stands true in an 'everything is D' world, which
we are clearly not in, and I don't see any risk of that happening any
time soon. I'm suspect it may never happen.

Dec 30 2014
Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 31 December 2014 at 16:12, Manu <turkeyman gmail.com> wrote:
Your view on ref only stands true in an 'everything is D' world, which
we are clearly not in, and I don't see any risk of that happening any
time soon. I'm suspect it may never happen.

And even then, passing by value in not something you would do! Why
would you ever pass some big struct by value? Are you relying on the
inliner? Inliners only inline tiny functions.
What about unoptimised/debug performance?

Dec 30 2014
Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 12/31/2014 07:17 AM, Manu via Digitalmars-d wrote:
And even then, passing by value in not something you would do! Why
would you ever pass some big struct by value?

Sure if it's an rvalue.

Jan 03 2015
Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 4 January 2015 at 10:38, Martin Nowak via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On 12/31/2014 07:17 AM, Manu via Digitalmars-d wrote:
And even then, passing by value in not something you would do! Why
would you ever pass some big struct by value?

Sure if it's an rvalue.

Really?
Don't get me started...

Jan 03 2015
"Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 31 December 2014 at 05:28:31 UTC, Andrei
Alexandrescu wrote:
The alternate hypothesis is "ref" is being misused. "ref" is
for propagating changes into the arguments. It should be rare
that code does not actually care for that. Unlike in C++, ref
is seldom needed for optimizing copies away. -- Andrei

Could you elaborate on that? Say I've got some big, expensive
struct I want to pass into a function efficiently. In C++ I'd do
this by const reference (or reference if I'm making changes).

What does D do that would make the ref unnecessary for
efficiency? I can't imagine the compiler doing any sort of copy
(even the efficient blig) being as fast as just passing in a
reference. There is also a problem if the struct has disabled
postblit. If the compiler silently turned something passed by
value into a secret reference then it would open the door for

It is a shame that there is a conflation between an optimization
and a tool for more flexible code structure. It makes it hard to
express your intention when you use ref.

With DIP25 it seems like passing in an rvalue by ref would be
safer and thus open it to being allowed.

Dec 31 2014
"Dicebot" <public dicebot.lv> writes:
On Monday, 29 December 2014 at 04:13:18 UTC, Andrei Alexandrescu
wrote:
Walter's reasoning was: we have inout for propagating
qualifiers from a parameter ("this" is also a parameter) to the
output, so we can use it for propagating aliasing information
as well.

Yay! I have been asking for it since scope threads started :)

I like the intention behind the DIP and I think idea itself is
sound and fits naturally into existing language.

But this example confuses me:

safe ref int wrongIdentity(ref int x) {
return x; // ERROR! Cannot return a ref, please use "ref
inout"
}

safe ref int identity(ref inout int x) {
return x; // fine
}

If existing meaning of is to be kept too second example should
look like this:

safe ref inout int identity(ref inout int x) {
return x; // fine
}

otherwise it allows silent casting of const reference to mutable
one!

Dec 29 2014
Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 29 December 2014 at 14:13, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On 12/28/14 7:40 PM, Manu via Digitalmars-d wrote:
On 28 December 2014 at 13:09, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
Walter and I have been working on revamping DIP25, which focuses on
tightening the screws of ref. This should then simplify DIP69
significantly.

Thanks,

Andrei

I could generally understand the intent, but I don't really understand
the connection between ref and inout.
They seem like unrelated things. I feel like conflating them could
only lead to unexpected problem cases when the concepts coincide
naturally, but the intent wasn't this assigned special case.
I wonder if we're just narrowing the window of edge cases, and
possibly into a slightly more awkward position for later fixes?

Walter's reasoning was: we have inout for propagating qualifiers from a
parameter ("this" is also a parameter) to the output, so we can use it for
propagating aliasing information as well.

Okay, that's an interesting perspective. I'm not sure I'm feeling it,
but I'll see how it sits overnight :)
The problem is that inout is clearly a type modifier; it resolves to
const, or immutable... adding additional conceptual baggage that's not
type-related seems problematic. Some non-type part of it's meaning
will be lost (or incorrectly transferred) in templates?

One idea we discussed was to use "return" like this:

ref int fun(return ref int x); // may return x

Walter didn't like it. I'm somewhat neutral.

It feels like a problem for 'scope' to me.

Any examples of cases when having inout do both would cause trouble?

Well, the case where something should be (or already is) inout, but
it's not intended for it to be safe to return from the function. It
remains unsafe, even though we've specified the magic special case
that tells the compiler it's okay.

I'd like to see 'ref inout(int)' rather than 'ref inout int', to make
inout look like the type modifier that it is, rather than a storage
class, which it isn't.
That distinction made me start second-guessing my assumptions
throughout, and reduced my confidence in my understanding of the
proposal.

When applied to a parameter, the parens are redundant.

A terrible decision if you ask me. I really prefer to see the parens
present on type modifiers, since they affect the 'layering' of type
modifiers, and also distinguish them from storage classes.

const int *: is it const(int)*, or const(int*)?
What about when layers are deeper: const(int*)[]?
You can produce any number of unclear scenarios of this kind.

or:
void eg(ref const S x)
{
f(x);
}

void f(T)(T x) // <- x is const, but not ref? why did some
attributes disappear but not others?
{
}

I like the clear visual distinction so people aren't wondering what happened.

I'd also like to know how this will help DIP69?

Just takes the entire ref handling out of the equation.

Then DIP69 seems to lose all purpose?
The whole thing is about safer indirections.

I can't imagine how
this could help DIP69 address the basic problems I was concerned with
(ie, distilling towards; 'storage class' is practically a bad design
for D, and my numerous rants and walls of text that follow).

I did want to say something about this. I've given a close read to the "Lost
a new commercial user this week" thread, through and through. It seems I've
identified a problem that belongs to us. ("Us" is a vacuous term meaning
"the leaders of the D community").

My initial read of your complaint went like this: it's about Windows (I
don't even have an installation), it's about vibe.d (haven't used it yet),
and it's also discussing documentation (which is something we can indeed
improve and I know how to). So a large part of the problem wasn't even mine
to work on.

I was giving a context with vibe.d, but I think they key take-aways were:

First-impressions; in our case, that was Windows environment setup,
but the point should be taken generally, and that includes IDE
integration. The effect of a poor experience here is eroding user
confidence before they've even written a single line of code.
Expectations are high, other programming communities are nailing this.

Debugging was the biggest issue, and turned out to be the dealbreaker.
We couldn't get behind something that we were unable to fix if we have
to. (I say 'we', meaning the general office perception, and that
perception was definitely coloured by the prior experiences re;
first-impressions)

Also documentation received a lot of criticism from the new-users,
although I didn't identify it as a deal-breaker. I experienced this
same frustration myself years ago. It's easy to address, I just wanted
to demonstrate importance.

Trust me that these guys were REALLY excited to try out D when we got
started. But their confidence was eroded very quickly by these factors
in aggregate.
I think D will get another shot with this lot at some later stage when
demonstrable progress has been made.

Others harbored similar perceptions. The corollary has been that essentially
you're asking them to stop working on D aspects they do care about and start
working on D aspects you and others care about - all on their free time.

I've already argued against this assertion, because it got kind of
aggressive. I was just reporting a case-study.
People can do whatever they want, I'm only trying to reaffirm the
reality of the importance of the same stuff that I've been going on
about since the day I showed up here.
There has been really great improvement, and we're getting awfully
close to the line, but we're still just a little way short.

It's a shame, because that boring stuff that nobody is interested in
working on is inhibiting people from getting amongst the cool stuff
that's going on here.

Then I figured we must take ownership of D issues. Your initial post was
pure and simple user feedback - a knowledgeable and well-informed and
well-meaning user but nevertheless a user who is not quite willing to roll
sleeves up and proceed with adding work. If we consider ourselves a
free-wheeling grassroots tribe, best we can do invite you to do the work and
review and merge it in (or snicker at you if you're not up for it). If, on
the other hand, we want to be a real organization, we must take the feedback
and own it.

A simple simile: say you mention to the manager of a grocery store that they
should have more organic fruit, and mention anecdotes of potential customers
shunning the store because it doesn't. If the store is a cooperative of
folks selling stuff they grow on their own, the manager might invite you to
join in with your produce. If, on the other hand, the store is an
established supermarket, they'd do good to take your suggestion seriously.

We're in the "cooperative" stage of D, and we need to move toward the
"established organization" stage. We should start transitioning to that next
year; part of it is I plan to look seriously at the non-profit organization
angle.

Right, this will be interesting. First I've heard of it.
I'm sure corporate users would put their money on the table if they
were purchasing some sort of support package, ie, greater confidence
in the tooling and infrastructure.
Especially in Windows-land, we're accustomed to paying for polished experiences.

There is a rub though. Not only you're telling what we'd need to do to be
more successful, you're also telling us how to do it. Please don't. We are
not adding type qualifiers to D if we can avoid it, and generally we want to
achieve what we need to achieve with minimum aggravation. Instead please
focus on what you're trying to accomplish, not on whether an artifact is a
type qualifier or a storage class. Thanks.

I only make the distinction because years of experience to date has
demonstrated clearly that the storage class concept is the source of
most of the awkward language problems I encounter.
Focusing on the current high-level goal will only lead to
context-specific patches (ie, further edge cases), and in this case
where I can clearly see the root of a series of problems spanning
years, it seems like the wrong thing to do.
There is time to approach a problem as you say, but I don't think this
is one of them. That said, if there is a vision presented that keeps
storage class and fixes the problems, I'm all for it, but nobody's
presented one, I can't envision one, and I've thought about it a lot.
The solution practically implies building a system of tools to
manipulate storage classes that parallels the existing system for
types... I don't see the point.

Surely it's not a bad thing to explore the thought that 'storage
class' may have actually been a mistake? There's room for retrospect.
You don't need to defend a bad idea when it's proven to be a problem.

ref is basically a broken design, it works in only the simplest of use
cases, and otherwise adds unwieldy complication to any more complex
language structures. The primary reason for that is because
semantically, it lives external to the 'meat' of the D language.
I suspect its original design is the direct result of the kind of
approach to the problem you're asking me to take; "user wants to pass
by ref, we'll try something that satisfies exactly the target use
case, and tries to isolate itself from any language side-effects", but
I think that attempt to isolate itself from cascading side-effects is
precisely the reason for all of it's awkward side-effects.
Perhaps there will be awkward side-effects either way? ...in this case
though, we have no tools to mitigate them manually. Code duplication
and text mixin are the only effective tools we have to manage ref
problems.

Dec 29 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/29/14 4:40 PM, Manu via Digitalmars-d wrote:
On 29 December 2014 at 14:13, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On 12/28/14 7:40 PM, Manu via Digitalmars-d wrote:
I'd also like to know how this will help DIP69?

Just takes the entire ref handling out of the equation.

Then DIP69 seems to lose all purpose?
The whole thing is about safer indirections.

DIP69 allows defining entire variables with "scope", something DIP25
does not address (but helps enforcing safety for).

I was giving a context with vibe.d, but I think they key take-aways were:

First-impressions; in our case, that was Windows environment setup,
but the point should be taken generally, and that includes IDE
integration. The effect of a poor experience here is eroding user
confidence before they've even written a single line of code.
Expectations are high, other programming communities are nailing this.

Debugging was the biggest issue, and turned out to be the dealbreaker.
We couldn't get behind something that we were unable to fix if we have
to. (I say 'we', meaning the general office perception, and that
perception was definitely coloured by the prior experiences re;
first-impressions)

Also documentation received a lot of criticism from the new-users,
although I didn't identify it as a deal-breaker. I experienced this
same frustration myself years ago. It's easy to address, I just wanted
to demonstrate importance.

Trust me that these guys were REALLY excited to try out D when we got
started. But their confidence was eroded very quickly by these factors
in aggregate.
I think D will get another shot with this lot at some later stage when
demonstrable progress has been made.

Yah, I hear ya. We need to muster talent and funds to make all that happen.

Others harbored similar perceptions. The corollary has been that essentially
you're asking them to stop working on D aspects they do care about and start
working on D aspects you and others care about - all on their free time.

I've already argued against this assertion, because it got kind of
aggressive. I was just reporting a case-study.
People can do whatever they want, I'm only trying to reaffirm the
reality of the importance of the same stuff that I've been going on
about since the day I showed up here.
There has been really great improvement, and we're getting awfully
close to the line, but we're still just a little way short.

It's a shame, because that boring stuff that nobody is interested in
working on is inhibiting people from getting amongst the cool stuff
that's going on here.

Yah, and I used to somehow consider the community was at "fault" about
it. There is something wrong when people don't have the time to
contribute because they're too busy arguing in the forums - even the
most trivial matters that would literally take vastly shorter time to
actually fix. Then I thought it might be a failure of leadership: it's
Walter and I who do something wrong if we're unable to rally the
community into action. I'm open to suggestions on how to do better going
forward.

Andrei

Dec 30 2014
Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 29/12/14 05:13, Andrei Alexandrescu via Digitalmars-d wrote:
I did want to say something about this. I've given a close read to the "Lost a
new commercial user this week" thread, through and through. It seems I've
identified a problem that belongs to us. ("Us" is a vacuous term meaning "the
leaders of the D community").

My initial read of your complaint went like this: it's about Windows (I don't
even have an installation), it's about vibe.d (haven't used it yet), and it's
also discussing documentation (which is something we can indeed improve and I
know how to). So a large part of the problem wasn't even mine to work on.

Others harbored similar perceptions. The corollary has been that essentially
you're asking them to stop working on D aspects they do care about and start
working on D aspects you and others care about - all on their free time.

A few thoughts on this.  (This turned a bit longer than expected in the
writing,
so I've highlighted some TL;DR sections to highlight key ideas.)

I think that one of the most common sources of community friction in open
source
is people mistaking being _asked_ to work on something that someone else cares
about, for being _expected_ to do so.

That's very unfortunate, because it means that all too often people will come
into a community, full of enthusiasm for this new thing they've discovered,
make
some suggestions, and get shot down like they're some sort of plague carrier.
(The D community is pretty good at not doing this with newcomers, but deals
less
well with people repeatedly raising ideas; more on that in a moment.)

Obviously, there are people who display an enormous sense of entitlement, who
are rude or just throw demands around in a very arrogant way.  But simply
saying, "I want this", "I need this", or "I think this would be a good idea"
should not IMO be a trigger for criticism or hostility.  Most of the time,
people do understand the fundamental constraints of a volunteer community with
limited resources, and what they are interested in having is either
acknowledgement of a good idea or use-case (preferably with something getting
onto a TODO list, but not necessarily with any priority), or feedback that
helps
them understand alternative ways to solve their problem.  (Caveat: it matters
whether the problem is actually solved, or just worked around.)

----------------------------------------------------------------------------
TL;DR: I think it would be good to have a strong community guideline that
people
are not to be criticized or treated badly for having requests or suggestions,
even if they are not willing to implement them themselves.  The quid pro quo is
that it's necessary to be (calmly) candid with people about the limits of
_only_
contributing ideas or requests: "You can ask but not demand".
----------------------------------------------------------------------------

The other observation is that, often, what frustrates core contributors about
people coming in with ideas and requests and so on, is that responding to that
takes time and effort and often distracts from limited time available to
deliver
actual work.  It can be very, very wearing having to explain to people time and
time again why something is a certain way, or to have to make the case yet
again
why X is not considered a priority, or whatever.

Now, in some cases, these problems are self-inflicted.  I've encountered core
contributors in some communities who simply _could not let go_ of the need to
prove someone else wrong, or to explain to the n'th degree why something was
not
possible.  (This interacts very badly with me, because I find it very difficult
to let go of a discussion where I feel that I've been misunderstood:-)  In
other
cases I've seen core contributors regularly engage in rudeness or sometimes
even
virulent personal attacks, and then bemoan how demotivating it is having to
deal
with belligerent arguments on the mailing lists.  Thankfully the D community
sees very little of this.

More often, it's simply a result of the discrepancy between numbers of
contributors and numbers of (verbally active) users -- and it only gets
compounded by the feeling that, if people spent half the time contributing that
they spent arguing, far more things would get done and the core contributors
would have a much easier time of it.

IMHO there are two important things to address here.  One is to give a lot of
priority to entry blockers -- to the things that prevent people from becoming
users or contributors.  Difficult installation experiences, obscure
dependencies, weird or out-of-date tools etc. are all things that are boring
but
important to address because the work to solve them can pay off massively in
terms of how many people are willing to get involved.  (D's move to GitHub is a
great example.)

Obviously volunteer contributors can't be obliged to accept these priorities,
but it should be possible to highlight and stress them as key things for the
project, as well as maybe engaging in some outreach to try and invite people
outside the current community to consider contributing their expertise.  There
could also be special rewards for people who deliver particularly important
goals (I'm thinking of things like signed copies of TDPL with personalized
thank-you notes; personally I reckon such things may be more precious than a
financial bounty:-).

----------------------------------------------------------------------------
TL;DR: When setting project priorities, put a real stress on entry problems,
and
consider outreach if the existing community doesn't seem able or willing to
engage with something important.  And be creative with the rewards for good
stuff :-)
----------------------------------------------------------------------------

The other is to embrace the fact that past a certain scale, there are always
going to be lots of people who are keen to take place in community discussion
(because hey, it's FUN:-) but who for whatever reason are not going to
contribute code or documentation.  The opportunity here is to ensure that key
knowledge is spread among these people, that they have good understanding of
the
what/where/why of the state of development, so that they are in a position to
bear the brunt of the explanation and conversation duties; ideally, they would
(simply by doing what they enjoy naturally) take away a lot of the need for
core
contributors to engage in day-to-day forum conversation.

In other words, you try and scale things so that core contributors primarily
talk with and guide regular forum participants, and they talk with other
people,
and get recognition for the value of what they're doing (any easy reward might
be, for example, the right to have an  dlang.org email address).  Note that it
doesn't need to be some sort of official role; there must be plenty of people
who might balk at the idea of community commitments or duties, who will
nevertheless do this well if simply engaged with.

----------------------------------------------------------------------------
TL;DR: Enable enthusiastic forum participants to be the front line of
communication, to take the heat off the core devs.
----------------------------------------------------------------------------

Then I figured we must take ownership of D issues. Your initial post was pure
and simple user feedback - a knowledgeable and well-informed and well-meaning
user but nevertheless a user who is not quite willing to roll sleeves up and
proceed with adding work. If we consider ourselves a free-wheeling grassroots
tribe, best we can do invite you to do the work and review and merge it in (or
snicker at you if you're not up for it). If, on the other hand, we want to be a
real organization, we must take the feedback and own it.

Even allowing for the difference between grassroots vs. organized projects, I
personally think it's one of the most counter-productive sides of open source
culture, that it's considered OK to snicker at people who don't want to get
their hands dirty.  There are lots of reasons people can't or won't contribute
at any given moment; it surely suffices to politely point out the limitations
of
non-involvement, and deal firmly with the handful of nasty people who get
abusive when that happens.

I'm really happy to see your resolve on the need to find ways to "take
ownership" of user issues.  It's been one of my regular sadnesses, seeing
various people (Manu and others) be very committed in providing feedback and
use-case scenarios, and not getting the engagement that their insight deserves.

A simple simile: say you mention to the manager of a grocery store that they
should have more organic fruit, and mention anecdotes of potential customers
shunning the store because it doesn't. If the store is a cooperative of folks
selling stuff they grow on their own, the manager might invite you to join in
with your produce. If, on the other hand, the store is an established
supermarket, they'd do good to take your suggestion seriously.

Yes, but :-)  A smart cooperative will still take on board the feedback and
consider if it might be worthwhile doing something themselves, even if it's not
directly in line with their personal interests.  In terms of how D can do
things
better, that might include trying to find better ways of documenting user
feedback and trying to better highlight worthwhile projects.  That might be
possible to organize independent of your next suggestion.

We're in the "cooperative" stage of D, and we need to move toward the
"established organization" stage. We should start transitioning to that next
year; part of it is I plan to look seriously at the non-profit organization
angle.

That's really great to hear; I don't want to say anything to anticipate or
prejudge what you have in mind, but I am looking forward to further elaboration
of this idea.

Jan 01 2015
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/1/15 10:45 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
On 29/12/14 05:13, Andrei Alexandrescu via Digitalmars-d wrote:
I did want to say something about this. I've given a close read to the
"Lost a
new commercial user this week" thread, through and through. It seems I've
identified a problem that belongs to us. ("Us" is a vacuous term
meaning "the
leaders of the D community").

My initial read of your complaint went like this: it's about Windows
(I don't
even have an installation), it's about vibe.d (haven't used it yet),
and it's
also discussing documentation (which is something we can indeed
improve and I
know how to). So a large part of the problem wasn't even mine to work on.

Others harbored similar perceptions. The corollary has been that
essentially
you're asking them to stop working on D aspects they do care about and
start
working on D aspects you and others care about - all on their free time.

A few thoughts on this.  (This turned a bit longer than expected in the
writing, so I've highlighted some TL;DR sections to highlight key ideas.)

[snip]

TL;DR: I think it would be good to have a strong community guideline
that people are not to be criticized or treated badly for having
requests or suggestions, even if they are not willing to implement
them themselves.  The quid pro quo is that it's necessary to be
(calmly) candid with people about the limits of _only_ contributing
ideas or requests: "You can ask but not demand".

What would be an appropriate place to put this?

Andrei

Jan 02 2015
"HaraldZealot" <harald_zealot tut.by> writes:
 TL;DR: I think it would be good to have a strong community
guideline
that people are not to be criticized or treated badly for
having
requests or suggestions, even if they are not willing to
implement
them themselves.  The quid pro quo is that it's necessary to be
(calmly) candid with people about the limits of _only_
contributing
ideas or requests: "You can ask but not demand".

What would be an appropriate place to put this?

Andrei

Any kind of main place, for example first page of dlang.org, but
not alone.
I have suggestion in my mind for a month at least:
For D's community is good to formulate something like principles
or axiomata. (Because as I see, many discussion goes round and
round about similar things).

One of those principle may sound like this for example:

__D is safe by default and fast when need.__

(This about general design of D, for example about garbage
collection). Main page has something like this but in descriptive
not rule-provided form. After formulating such maxima many
discussion calming itself, because part of ideas will follow
global goals and another contradict.

In my view such principles have to cover following aspects:
design of D (about safety, speed, multiparadigmality, glitchness,
smoothness  and so on), evolution of D (in such cases breaking
change is allowed and about deepness of breakage, phobos and its
topics coverage and so on)  and community cooperation (yes, it is
suggested by Joseph Rushton Wakeling community guidline).

IMO discussion about such axiomata (when comunity interesting in)
need own topic.

Jan 02 2015
Leandro Motta Barros via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, Jan 2, 2015 at 7:26 AM, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

On 1/1/15 10:45 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:

On 29/12/14 05:13, Andrei Alexandrescu via Digitalmars-d wrote:

I did want to say something about this. I've given a close read to the
"Lost a
new commercial user this week" thread, through and through. It seems I've
identified a problem that belongs to us. ("Us" is a vacuous term
meaning "the
leaders of the D community").

My initial read of your complaint went like this: it's about Windows
(I don't
even have an installation), it's about vibe.d (haven't used it yet),
and it's
also discussing documentation (which is something we can indeed
improve and I
know how to). So a large part of the problem wasn't even mine to work on.

Others harbored similar perceptions. The corollary has been that
essentially
you're asking them to stop working on D aspects they do care about and
start
working on D aspects you and others care about - all on their free time.

A few thoughts on this.  (This turned a bit longer than expected in the
writing, so I've highlighted some TL;DR sections to highlight key ideas.)

[snip]

TL;DR: I think it would be good to have a strong community guideline
that people are not to be criticized or treated badly for having
requests or suggestions, even if they are not willing to implement
them themselves.  The quid pro quo is that it's necessary to be
(calmly) candid with people about the limits of _only_ contributing
ideas or requests: "You can ask but not demand".

What would be an appropriate place to put this?

We could post an FAQ or something FAQ-like every month or so, including
things like "can I ask for things I want?" or "what should I post to each
forum?".

LMB

Jan 02 2015
Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 02/01/15 10:26, Andrei Alexandrescu via Digitalmars-d wrote:

I'm glad it seems useful; I wondered after writing if it was a bit too much of
a
rambling mess :-P

TL;DR: I think it would be good to have a strong community guideline
that people are not to be criticized or treated badly for having
requests or suggestions, even if they are not willing to implement
them themselves.  The quid pro quo is that it's necessary to be
(calmly) candid with people about the limits of _only_ contributing
ideas or requests: "You can ask but not demand".

What would be an appropriate place to put this?

How about a link at the top of the forum.dlang.org page saying something like,
"Before posting, please read our _community guidelines_" ?  With the page
to containing advice like the above.

I know that there's always been a lot of pride that we've always been able to
get along without some kind of code of conduct, but ... well, guidelines are
not
the same as a code, and anyway, not having guidance just doesn't scale in my
experience.

Jan 02 2015
Walter Bright <newshound2 digitalmars.com> writes:
On 1/2/2015 1:17 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
How about a link at the top of the forum.dlang.org page saying something like,
"Before posting, please read our _community guidelines_" ?  With the page
to containing advice like the above.

I know that there's always been a lot of pride that we've always been able to
get along without some kind of code of conduct, but ... well, guidelines are
not
the same as a code, and anyway, not having guidance just doesn't scale in my
experience.

I've been extremely reluctant to have any sort of official conduct code. I
prefer a gentle nudge on a case by case basis, and just deleting the posts of
incorrigible trolls.

Leading by example, implicit expectations of good conduct, and peer pressure
can
be amazingly effective.

A code of conduct that says things like "don't harass others, no illegal
content, etc." are just pointless, patronizing and frankly insulting. If
someone
wants to behave badly, is a code of conduct really going to change their mind?

Caltech, which I attended, was very influential on me in that it is the only
school in the world that has a real honor system. Nobody else has the guts to
try it. I've had good success applying the principles of it ever since, and
this
forum is one of them.

Essentially, the default attitude is to trust that people are honest and
decent.
I don't tell them how to be honest and decent, I just assume that they are. It
works amazingly well.

(At Caltech, for example, exams are not proctored by institute policy. You can
even take time limited tests home with you and do them when you're ready. The
number of Fs students get on exams is a pretty good indicator that when they're
trusted, they rise to the occasion.)

I've noticed that the D community is an unusually honorable and decent group of
people. Maybe that's due in some part to implicitly expecting them to be so, or
maybe that's my own hubris. But I am extremely unwilling to risk that by
posting
a "code of conduct" that assumes people need lessons in how to behave.

Jan 02 2015
"Tobias Pankrath" <tobias pankrath.net> writes:
 I've been extremely reluctant to have any sort of official
conduct code. I prefer a gentle nudge on a case by case basis,
and just deleting the posts of incorrigible trolls.

Leading by example, implicit expectations of good conduct, and
peer pressure can be amazingly effective.

Yes, we don't need official forum rules, but we have to agree on
the unofficial ones. If people with d street cred step up and
tell people if they go overboard everyone will follow. If they
point to some official rules, those how break them will just
argue that they technically didn't. We have no need for lawyers
here.

Jan 02 2015
Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 02/01/15 23:50, Walter Bright via Digitalmars-d wrote:
I've been extremely reluctant to have any sort of official conduct code. I
prefer a gentle nudge on a case by case basis, and just deleting the posts of
incorrigible trolls.

Yes, I'm aware of that, and I do have a lot of sympathy with your point of view.

Leading by example, implicit expectations of good conduct, and peer pressure
can
be amazingly effective.

All very true.

A code of conduct that says things like "don't harass others, no illegal
content, etc." are just pointless, patronizing and frankly insulting. If
someone
wants to behave badly, is a code of conduct really going to change their mind?

As regards the specific provisions you cite, sure, that stuff is almost always
annoying and patronizing.  But I think that what I was proposing was slightly
more subtle.

I do think there's a big difference between friendly guidelines, versus a "code
of conduct".  The most obvious is that the former are intended to be helpful
advice, not a list of expectations.

Caltech, which I attended, was very influential on me in that it is the only
school in the world that has a real honor system. Nobody else has the guts to
try it. I've had good success applying the principles of it ever since, and
this
forum is one of them.

Essentially, the default attitude is to trust that people are honest and
decent.
I don't tell them how to be honest and decent, I just assume that they are. It
works amazingly well.

I agree.  However, I think that the ability to rely on an honour system does
depend to a certain extent on the numbers of people you are dealing with.

One of the benefits of guidelines or codes of conduct is not so much in
instructing people what to do, as much as in constraining the leadership or
authority figures in an organization to behave fairly and consistently in
acting
against troublemakers.  This becomes quite apparent in some moderated forums
where the "moderation" in practice amounts to "What ticks off the current
moderator at this particular moment".  Such communities are rarely fun to be
part of.

Obviously D does not have such a problem right now, but as the number of people
active on the forums grows, there are inevitably going to be more and more
instances of people behaving antisocially, and that does in turn make it more
important to have some mechanism to ensure they are dealt with fairly and not
arbitrarily.

There are also some particular personality traits that can lead people to have
problems understanding how their behaviour is impacting on others -- obvious
examples are people on some parts of the autistic spectrum or people who are
experiencing mental health issues.  Firm guidelines can sometimes be helpful
here in terms of defining clear boundaries that people can look to when they
may
not entirely trust their own judgement.  They can also be _very_ important in
helping to ensure that other community members do not victimise someone who
seems to be acting antisocially, but may in fact be experiencing issues that
prevent them from realizing how they are coming across.

I've noticed that the D community is an unusually honorable and decent group of
people. Maybe that's due in some part to implicitly expecting them to be so, or
maybe that's my own hubris. But I am extremely unwilling to risk that by
posting
a "code of conduct" that assumes people need lessons in how to behave.

If you think of it less as an attempt to tell people how to behave, and more of
a sanity check for community leaders to think, "Hang on, am I right to call out
this person for their behaviour?", then a code of conduct can make more sense.
In the (hopefully rare) event that a community member does need to be dealt
with
firmly, it can also be helpful to have something consistent to point to to
explain such decisions.

That said, I don't see any pressing need for something formal at this point in
time.  Some friendly suggestions, guidelines or advice -- that's another thing
and doesn't need to be provided in a formal way.

Jan 02 2015
Walter Bright <newshound2 digitalmars.com> writes:
On 1/2/2015 4:05 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
On 02/01/15 23:50, Walter Bright via Digitalmars-d wrote:
That said, I don't see any pressing need for something formal at this point in
time.  Some friendly suggestions, guidelines or advice -- that's another thing
and doesn't need to be provided in a formal way.

If it's posted with a link, it's then formal.

I handle things on a case by case basis (and there isn't much of it,
thankfully). It works well enough. We've got a community here we can be proud
of.

Jan 02 2015
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/2/15 4:05 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
That said, I don't see any pressing need for something formal at this
point in time.  Some friendly suggestions, guidelines or advice --
that's another thing and doesn't need to be provided in a formal way.

So now should I close https://issues.dlang.org/show_bug.cgi?id=13928
that I just created? :o) -- Andrei

Jan 02 2015
Rikki Cattermole <alphaglosined gmail.com> writes:
On 3/01/2015 7:55 p.m., Andrei Alexandrescu wrote:
On 1/2/15 4:05 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
That said, I don't see any pressing need for something formal at this
point in time.  Some friendly suggestions, guidelines or advice --
that's another thing and doesn't need to be provided in a formal way.

So now should I close https://issues.dlang.org/show_bug.cgi?id=13928
that I just created? :o) -- Andrei

Please don't. While I understand Walters position to not formalizing a
set of do's and dont's, we do still need something even if its just a
mantra shown if a cookie is not present in the NG web interface.
It can be as simple as, this is a professional communication facility
for furthering the D programming language. Please respect the goals of
the community.

Jan 02 2015
Walter Bright <newshound2 digitalmars.com> writes:
On 1/2/2015 11:31 PM, Rikki Cattermole wrote:
On 3/01/2015 7:55 p.m., Andrei Alexandrescu wrote:
On 1/2/15 4:05 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
That said, I don't see any pressing need for something formal at this
point in time.  Some friendly suggestions, guidelines or advice --
that's another thing and doesn't need to be provided in a formal way.

So now should I close https://issues.dlang.org/show_bug.cgi?id=13928
that I just created? :o) -- Andrei

Yes.

Please don't. While I understand Walters position to not formalizing a set of
do's and dont's, we do still need something even if its just a mantra shown if
a
cookie is not present in the NG web interface.
It can be as simple as, this is a professional communication facility for
furthering the D programming language. Please respect the goals of the
community.

No evidence we need that, and if we did, that it would be effective. Explained
in a previous post.

Jan 03 2015
"Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 3 January 2015 at 00:06:10 UTC, Joseph Rushton
Wakeling via Digitalmars-d wrote:
Obviously D does not have such a problem right now, but as the
number of people active on the forums grows, there are
inevitably going to be more and more instances of people
behaving antisocially, and that does in turn make it more
important to have some mechanism to ensure they are dealt with
fairly and not arbitrarily.

I've heard this a few times before over the years, and it hasn't
happened yet. Perhaps we're not growing at the the necessary
rapid rate, but I think new people try to blend into what they
see other people doing, so as long as at any given time, the
majority of us behave fairly well, it will stay that way.

I agree with what you're saying about a fair process and I don't
think some guidelines about how to deal with trouble would be
bad, even if it is as simple as "please don't feed the trolls" or
even "turn the other cheek"*. But I also think we're doing OK as
it is right now and have been for a lot of years and probably
will be for many years more.

* fun fact, a lot of people see the "eye for an eye" thing as
being like a gross cruel and unusual punishment, but at the time,
it was actually quite progressive - it put limits on executive
power! If the rule is tooth for a tooth, the disciplinarian can't
arbitrarily decide to draw and quarter you because you punched
his buddy in the face. Goes to what you said about the fair
process.

Jan 03 2015
Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 03/01/15 15:42, Adam D. Ruppe via Digitalmars-d wrote:
I've heard this a few times before over the years, and it hasn't happened yet.
Perhaps we're not growing at the the necessary rapid rate, but I think new
people try to blend into what they see other people doing, so as long as at any
given time, the majority of us behave fairly well, it will stay that way.

I agree with what you're saying about a fair process and I don't think some
guidelines about how to deal with trouble would be bad, even if it is as simple
as "please don't feed the trolls" or even "turn the other cheek"*. But I also
think we're doing OK as it is right now and have been for a lot of years and
probably will be for many years more.

I think that's fair enough.  Bear in mind that what I actually proposed was a
guideline for one quite specific scenario, i.e. how to handle people asking for
features, proposing ideas, and so on, who were not willing or able to step up
and deliver them.

I'd be happy if that principle was simply accepted by core community members
(it
seems to have been) and promulgated by example and polite nudges.

Jan 04 2015
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/2/15 1:17 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
On 02/01/15 10:26, Andrei Alexandrescu via Digitalmars-d wrote:

I'm glad it seems useful; I wondered after writing if it was a bit too
much of a rambling mess :-P

TL;DR: I think it would be good to have a strong community guideline
that people are not to be criticized or treated badly for having
requests or suggestions, even if they are not willing to implement
them themselves.  The quid pro quo is that it's necessary to be
(calmly) candid with people about the limits of _only_ contributing
ideas or requests: "You can ask but not demand".

What would be an appropriate place to put this?

How about a link at the top of the forum.dlang.org page saying something
like, "Before posting, please read our _community guidelines_" ?  With
the page linked to containing advice like the above.

I know that there's always been a lot of pride that we've always been
able to get along without some kind of code of conduct, but ... well,
guidelines are not the same as a code, and anyway, not having guidance
just doesn't scale in my experience.

https://issues.dlang.org/show_bug.cgi?id=13928

Andrei

Jan 02 2015
Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1 Jan 2015 18:46, "Joseph Rushton Wakeling via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:
On 29/12/14 05:13, Andrei Alexandrescu via Digitalmars-d wrote:
I did want to say something about this. I've given a close read to the

"Lost a
new commercial user this week" thread, through and through. It seems I've
identified a problem that belongs to us. ("Us" is a vacuous term meaning

"the
leaders of the D community").

My initial read of your complaint went like this: it's about Windows (I

don't
even have an installation), it's about vibe.d (haven't used it yet), and

it's
also discussing documentation (which is something we can indeed improve

and I
know how to). So a large part of the problem wasn't even mine to work on.

Others harbored similar perceptions. The corollary has been that

essentially
you're asking them to stop working on D aspects they do care about and

start
working on D aspects you and others care about - all on their free time.

A few thoughts on this.  (This turned a bit longer than expected in the

writing, so I've highlighted some TL;DR sections to highlight key ideas.)
I think that one of the most common sources of community friction in open

source is people mistaking being _asked_ to work on something that someone
else cares about, for being _expected_ to do so.
That's very unfortunate, because it means that all too often people will

come into a community, full of enthusiasm for this new thing they've
discovered, make some suggestions, and get shot down like they're some sort
of plague carrier. (The D community is pretty good at not doing this with
newcomers, but deals less well with people repeatedly raising ideas; more
on that in a moment.)
Obviously, there are people who display an enormous sense of entitlement,

who are rude or just throw demands around in a very arrogant way.  But
simply saying, "I want this", "I need this", or "I think this would be a
good idea" should not IMO be a trigger for criticism or hostility.  Most of
the time, people do understand the fundamental constraints of a volunteer
community with limited resources, and what they are interested in having is
either acknowledgement of a good idea or use-case (preferably with
something getting onto a TODO list, but not necessarily with any priority),
or feedback that helps them understand alternative ways to solve their
problem.  (Caveat: it matters whether the problem is actually solved, or
just worked around.)

I've stopped here (I'm reading from a phone and travelling), but some
thoughts come to mind when it comes to persistent offenders/questions.

1. DIPs should be process of getting a new feature / breaking change
through - not the ML.

People who want changes strong enough should be encouraged to raise one.

2. Why does D not do X? And other frequent questions should go in a FAQ
with a clear answer.  This hopefully isn't the rule but I sense sometimes
the reason certain things come up again and again are because either of the
following:

a. Responses vary or change over time.  So the original reason and
motivation for rejection gets lost.

b. There is no official rejection stamp for ideas that spring up from the
ML compared to DIPs.

Having this in a FAQ serves the purposes of both (a) and (b).

3. Bounties were supposed to address some aspects of feature driven goals.

I don't think this works in practice but the thought process seemed sound,
in terms of:

a.  Someone has an idea and raises it in the ML.
b. A DIP is created, along with a bugzilla report and bounty.
c. More bounties that go in drives popularity and the likelihood of a PR
being raised to implement the DIP.

I don't have an alternate proposal to this, but I recognize that upvotes in
bugzilla don't drive incentives either.

Though you may have raised some good points on these. :)

Iain.

Jan 03 2015
Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/27/14 10:09 PM, Andrei Alexandrescu wrote:
Walter and I have been working on revamping DIP25, which focuses on
tightening the screws of ref. This should then simplify DIP69
significantly.

ref int hun() inout { return b; }

This doesn't make sense. inout cannot cast to mutable.

Other than that, there is an issue with taking ref mutable parameters.

For example, you cannot implement an increment function:

ref int increment(ref int x) { return ++x;}

marking x as inout makes it effectively const during the body of the
function, so such a function would be banned. I'm sure there are some of
these in some code somewhere, I wouldn't be surprised if phobos had some.

I like the idea of inferring lifetime based on inout, and I think that
connection is sound. But I don't like the idea of *requiring* inout to
qualify ref returns of parameters. It's too restrictive.

-Steve

Dec 29 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/29/14 6:07 AM, Steven Schveighoffer wrote:
On 12/27/14 10:09 PM, Andrei Alexandrescu wrote:
Walter and I have been working on revamping DIP25, which focuses on
tightening the screws of ref. This should then simplify DIP69
significantly.

ref int hun() inout { return b; }

This doesn't make sense. inout cannot cast to mutable.

Yah, the DIP should clarify that new behavior. Thanks. -- Andrei

Dec 29 2014
Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/29/14 10:51 AM, Andrei Alexandrescu wrote:
On 12/29/14 6:07 AM, Steven Schveighoffer wrote:
On 12/27/14 10:09 PM, Andrei Alexandrescu wrote:
Walter and I have been working on revamping DIP25, which focuses on
tightening the screws of ref. This should then simplify DIP69
significantly.

ref int hun() inout { return b; }

This doesn't make sense. inout cannot cast to mutable.

Yah, the DIP should clarify that new behavior. Thanks. -- Andrei

Huh? This behavior cannot be allowed.

If we can return mutable ref to a member when calling a member function
on a const or immutable object, then we are in violation of const.

What is the point of the above? in such a function, what is typeof(this)?

Even if you can make up rules to make this sane, it's going to be
boatloads more confusing than today's situation with inout.

-Steve

Dec 29 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/29/14 8:09 AM, Steven Schveighoffer wrote:
On 12/29/14 10:51 AM, Andrei Alexandrescu wrote:
On 12/29/14 6:07 AM, Steven Schveighoffer wrote:
On 12/27/14 10:09 PM, Andrei Alexandrescu wrote:
Walter and I have been working on revamping DIP25, which focuses on
tightening the screws of ref. This should then simplify DIP69
significantly.

ref int hun() inout { return b; }

This doesn't make sense. inout cannot cast to mutable.

Yah, the DIP should clarify that new behavior. Thanks. -- Andrei

Huh? This behavior cannot be allowed.

If we can return mutable ref to a member when calling a member function
on a const or immutable object, then we are in violation of const.

What is the point of the above? in such a function, what is typeof(this)?

Even if you can make up rules to make this sane, it's going to be
boatloads more confusing than today's situation with inout.

I tend to agree. You seem to have shown that reusing inout for scope
information becomes confusing. -- Andrei

Dec 29 2014
"Dicebot" <public dicebot.lv> writes:
On Monday, 29 December 2014 at 19:00:06 UTC, Andrei Alexandrescu
wrote:
I tend to agree. You seem to have shown that reusing inout for
scope information becomes confusing. -- Andrei

What is the problem with using inout exactly as it is now (==
both for argument and return type) but defining it to propagate
aliasing information as it is decribed in DIP25?

Dec 29 2014
Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/29/14 2:04 PM, Dicebot wrote:
On Monday, 29 December 2014 at 19:00:06 UTC, Andrei Alexandrescu wrote:
I tend to agree. You seem to have shown that reusing inout for scope
information becomes confusing. -- Andrei

What is the problem with using inout exactly as it is now (== both for
argument and return type) but defining it to propagate aliasing
information as it is decribed in DIP25?

It can, and I don't have a problem for that.

But I think disallowing:

ref T foo(T)(ref T t) { return t;}

Is no good. The DIP seems to be indicating inout can have another use
that has nothing to do with const, but I'm not exactly sure.

Ironically, inout used to be an alias for ref :)

-Steve

Dec 29 2014
"Dicebot" <public dicebot.lv> writes:
On Monday, 29 December 2014 at 19:54:33 UTC, Steven Schveighoffer
wrote:
On 12/29/14 2:04 PM, Dicebot wrote:
On Monday, 29 December 2014 at 19:00:06 UTC, Andrei
Alexandrescu wrote:
I tend to agree. You seem to have shown that reusing inout
for scope
information becomes confusing. -- Andrei

What is the problem with using inout exactly as it is now (==
both for
argument and return type) but defining it to propagate aliasing
information as it is decribed in DIP25?

It can, and I don't have a problem for that.

But I think disallowing:

ref T foo(T)(ref T t) { return t;}

Is no good.

It is to be disallowed only in  safe code, right?

The DIP seems to be indicating inout can have another use that
has nothing to do with const, but I'm not exactly sure.

I see its potential as a  generic wildcard for
attribute/qualifier propagation through the functions.

Dec 29 2014
Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/29/14 2:57 PM, Dicebot wrote:
On Monday, 29 December 2014 at 19:54:33 UTC, Steven Schveighoffer wrote:
On 12/29/14 2:04 PM, Dicebot wrote:
On Monday, 29 December 2014 at 19:00:06 UTC, Andrei Alexandrescu wrote:
I tend to agree. You seem to have shown that reusing inout for scope
information becomes confusing. -- Andrei

What is the problem with using inout exactly as it is now (== both for
argument and return type) but defining it to propagate aliasing
information as it is decribed in DIP25?

It can, and I don't have a problem for that.

But I think disallowing:

ref T foo(T)(ref T t) { return t;}

Is no good.

It is to be disallowed only in  safe code, right?

Even in safe code, if it's safe to do so, it should be allowed.

I think the driving point behind this push is that when you see:

ref T foo(ref T t);

how do you know if the return of foo is somehow related to t or not? The
DIP is saying if you return something related to t, you have to mark t
as inout. At least, this is my understanding. But this precludes doing
anything with a mutable t inside foo, since inout means "const within
the function".

The DIP seems to be indicating inout can have another use that has
nothing to do with const, but I'm not exactly sure.

I see its potential as a  generic wildcard for attribute/qualifier
propagation through the functions.

It's not generic at all. It's a concrete type qualifier that does not
generate a template. When inside an 'inout' function, anything marked as
inout is transitively const.

-Steve

Dec 29 2014
"Dicebot" <public dicebot.lv> writes:
On Monday, 29 December 2014 at 20:20:45 UTC, Steven Schveighoffer
wrote:
But this precludes doing anything with a mutable t inside foo,
since inout means "const within the function".

Hm, yes, this is indeed quite the problem. I have totally forgot
that compiler has no means of figuring out which invocation of
inout is currently used.

But something very similar feels necessary to me. There is
constness, lifetime, purity - inventing new dedicated keyword for
each case does not feel like scaling approach. Especially when
existing one is named so generic.

Dec 29 2014
Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/29/14 3:42 PM, Dicebot wrote:
On Monday, 29 December 2014 at 20:20:45 UTC, Steven Schveighoffer wrote:
But this precludes doing anything with a mutable t inside foo, since
inout means "const within the function".

Hm, yes, this is indeed quite the problem. I have totally forgot that
compiler has no means of figuring out which invocation of inout is
currently used.

But something very similar feels necessary to me. There is constness,
lifetime, purity - inventing new dedicated keyword for each case does
not feel like scaling approach. Especially when existing one is named so
generic.

My original inkling was to name it scoped const or sconst, since that's
what the proposal was originally named. The idea to use inout was
because of the allergic reaction all the maintainers had at the time to
adding any new keywords -- inout was fully superseded by ref, and
technically "available" without introducing any new keywords. I almost
wish we had never named it that, but I was too happy to have the feature
at the time.

I think it wouldn't be a bad idea to investigate a new way to express
attributes, but I think no matter what we do, we need to rein in the
explosion of attributes that needs to be put on every function.

-Steve

Dec 29 2014
"Dicebot" <public dicebot.lv> writes:
On Monday, 29 December 2014 at 21:29:21 UTC, Steven Schveighoffer
wrote:
I think it wouldn't be a bad idea to investigate a new way to
express attributes, but I think no matter what we do, we need
to rein in the explosion of attributes that needs to be put on
every function.

For that I think attribute inference is the way to go - though in
a bit more structured fashion than it was originally proposed
ages ago ("just infer everything")

Dec 29 2014
Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 30 December 2014 at 07:29, Steven Schveighoffer via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On 12/29/14 3:42 PM, Dicebot wrote:

I think it wouldn't be a bad idea to investigate a new way to express
attributes, but I think no matter what we do, we need to rein in the
explosion of attributes that needs to be put on every function.

The approach is to infer everything, right?
The only time you are required to make it explicit is when it's an
important detail of your API, and you want to receive compile errors
when you violate such explicit request.

Dec 29 2014
Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/29/14 8:10 PM, Manu via Digitalmars-d wrote:
On 30 December 2014 at 07:29, Steven Schveighoffer via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On 12/29/14 3:42 PM, Dicebot wrote:

I think it wouldn't be a bad idea to investigate a new way to express
attributes, but I think no matter what we do, we need to rein in the
explosion of attributes that needs to be put on every function.

The approach is to infer everything, right?
The only time you are required to make it explicit is when it's an
important detail of your API, and you want to receive compile errors
when you violate such explicit request.

This only works for templates. Unless we devise a new object scheme and

But I agree. The problem is, most times, you WANT to ensure your code is
safe pure nothrow (and now  nogc), even for template functions. That's
a lot of baggage to put on each signature. I just helped someone
recently who wanted to put  nogc on all the std.datetime code, and every
signature had these 4 attributes except a few. I tried to have him put a
big  safe: pure: nothrow:  nogc: at the top, but the occasional
exceptions made this impossible.

It's unfortunate we couldn't start with these being the defaults, and
then add the occasional  system,  unpure, and  throws where appropriate.

Some mechanism of aliasing attribute combinations is itching to get done :)

-Steve

Dec 30 2014
ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 30 Dec 2014 07:14:24 -0500
Steven Schveighoffer via Digitalmars-d <digitalmars-d puremagic.com>
wrote:

But I agree. The problem is, most times, you WANT to ensure your code is=

=20
safe pure nothrow (and now  nogc), even for template functions. That's=20
a lot of baggage to put on each signature. I just helped someone=20
recently who wanted to put  nogc on all the std.datetime code, and every=

=20
signature had these 4 attributes except a few. I tried to have him put a=

=20
big  safe: pure: nothrow:  nogc: at the top, but the occasional=20
exceptions made this impossible.
=20
It's unfortunate we couldn't start with these being the defaults, and=20
then add the occasional  system,  unpure, and  throws where appropriate.
=20
Some mechanism of aliasing attribute combinations is itching to get done =

:)

or at least the way to "undo" some attributes. we can "undo" " safe",
but what about "notrhow"? " nogc"? "const"? and, by the way, "final"
and "static"!

it's very handy to write something like this:
final:
nothrow:
nogc:
void foo () { ... }
...
// and ocasionally we need this:
virtual bar () throw  gc { ... }
// and go on with 'final nothrow  nogc'
...

sure, we can move bar to another place, or make ugly nestes "{}"
blocks, or invent some other workarounds. but they are still
workarounds, and this frustrates me alot. if we have a way to make
something default (final:), we MUST have a way to cancel that
defaults both temporary and permanently.

another nice D feature that is half-done.

Dec 30 2014
Walter Bright <newshound2 digitalmars.com> writes:
On 12/30/2014 4:14 AM, Steven Schveighoffer wrote:
But I agree. The problem is, most times, you WANT to ensure your code is  safe
pure nothrow (and now  nogc), even for template functions. That's a lot of
baggage to put on each signature. I just helped someone recently who wanted to
put  nogc on all the std.datetime code, and every signature had these 4
attributes except a few. I tried to have him put a big  safe: pure: nothrow:
nogc: at the top, but the occasional exceptions made this impossible.

The way to do it is one of:

1. reorganize the code so the non-attributed ones come first

2. write the attributes as:

safe pure nothrow  nogc {
... functions ...
}

... non attributed functions ...

safe pure nothrow  nogc {
... more functions ...
}

Jan 05 2015
Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/5/15 4:10 PM, Walter Bright wrote:
On 12/30/2014 4:14 AM, Steven Schveighoffer wrote:
But I agree. The problem is, most times, you WANT to ensure your code
is  safe
pure nothrow (and now  nogc), even for template functions. That's a
lot of
baggage to put on each signature. I just helped someone recently who
wanted to
put  nogc on all the std.datetime code, and every signature had these 4
attributes except a few. I tried to have him put a big  safe: pure:
nothrow:
nogc: at the top, but the occasional exceptions made this impossible.

The way to do it is one of:

1. reorganize the code so the non-attributed ones come first

2. write the attributes as:

safe pure nothrow  nogc {
... functions ...
}

... non attributed functions ...

safe pure nothrow  nogc {
... more functions ...
}

To give you an example of why that sucks, imagine that your accessor for
member_x is nothrow, but your setter is not. This means you either "make
an exception", or you just split up obvious file-mates into separate
corners. Source control gets confused if one of those attributes
changes. Nobody is happy.

Grouping by attributes is probably one of the worst ways to have

One of the most important reasons why unittests are so successful is
that you can just plop the code that tests a function right next to it.
So easy to find the code, so easy to maintain when you change the target
of the test. Making some way to bundle attributes, or be able to negate
currently one-way attributes would go a long way IMO.

-Steve

Jan 05 2015
Walter Bright <newshound2 digitalmars.com> writes:
On 1/5/2015 2:04 PM, Steven Schveighoffer wrote:
To give you an example of why that sucks, imagine that your accessor for
member_x is nothrow, but your setter is not. This means you either "make an
exception", or you just split up obvious file-mates into separate corners.
Source control gets confused if one of those attributes changes. Nobody is
happy.

Grouping by attributes is probably one of the worst ways to have

One of the most important reasons why unittests are so successful is that you
can just plop the code that tests a function right next to it. So easy to find
the code, so easy to maintain when you change the target of the test. Making
some way to bundle attributes, or be able to negate currently one-way
attributes
would go a long way IMO.

I know and agree. I was just responding to the 'impossible' characterization.

Jan 05 2015
Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/6/15 1:48 AM, Walter Bright wrote:
On 1/5/2015 2:04 PM, Steven Schveighoffer wrote:
To give you an example of why that sucks, imagine that your accessor for
member_x is nothrow, but your setter is not. This means you either
"make an
exception", or you just split up obvious file-mates into separate
corners.
Source control gets confused if one of those attributes changes.
Nobody is happy.

Grouping by attributes is probably one of the worst ways to have

One of the most important reasons why unittests are so successful is
that you
can just plop the code that tests a function right next to it. So easy
to find
the code, so easy to maintain when you change the target of the test.
Making
some way to bundle attributes, or be able to negate currently one-way
attributes
would go a long way IMO.

I know and agree. I was just responding to the 'impossible'
characterization.

OK, Mr. Literal :) Sorry, I should have said "impossible without totally
screwing up the code"

-Steve

Jan 06 2015
"Zach the Mystic" <reachzach gggmail.com> writes:
On Tuesday, 6 January 2015 at 06:48:34 UTC, Walter Bright wrote:
One of the most important reasons why unittests are so
successful is that you
can just plop the code that tests a function right next to it.
So easy to find
the code, so easy to maintain when you change the target of
the test. Making
some way to bundle attributes, or be able to negate currently
one-way attributes
would go a long way IMO.

I know and agree. I was just responding to the 'impossible'
characterization.

Is it bikeshedding time?? If so, I was thinking ' ~' to be the
universal canceller...  ~pure,  ~final. I'm only half kidding.

Jan 06 2015
"Dominikus Dittes Scherkl" writes:
On Monday, 5 January 2015 at 22:04:58 UTC, Steven Schveighoffer
wrote:
Making some way to bundle attributes, or be able to negate
currently one-way attributes would go a long way IMO.

Yeah. I wish it would be possilbe to do something like:

alias  smooth =  save pure nothrow  nogc;

and then use this instead.

Jan 06 2015
"bearophile" <bearophileHUGS lycos.com> writes:
Dominikus Dittes Scherkl:

Yeah. I wish it would be possilbe to do something like:

alias  smooth =  save pure nothrow  nogc;

and then use this instead.

You most probably want something more principled instead, as the
algebra of effects of Koka language
(http://rise4fun.com/Koka/tutorial/guide ) or something even
better.

Bye,
bearophile

Jan 06 2015
"Dominikus Dittes Scherkl" writes:
On Tuesday, 6 January 2015 at 09:11:10 UTC, bearophile wrote:
Dominikus Dittes Scherkl:

Yeah. I wish it would be possilbe to do something like:

alias  smooth =  save pure nothrow  nogc;

and then use this instead.

You most probably want something more principled instead, as
the algebra of effects of Koka language
(http://rise4fun.com/Koka/tutorial/guide ) or something even
better.

Bye,
bearophile

Sounds interesting, but would be hard to cover other attributes
(or effects) like  save and  nogc within this system.
And I think using alias for creating combined attributes by hand
would be easy to implement, not breaking any existing code and
handy enough for most common combinations.
And by the way, this would also allow to define ore remove the
as one wiches:
alias nogc =  nogc;
or vice versa:
alias  pure = pure;

Jan 06 2015
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 6 January 2015 at 09:11:10 UTC, bearophile wrote:
You most probably want something more principled instead, as
the algebra of effects of Koka language
(http://rise4fun.com/Koka/tutorial/guide ) or something even
better.

Thanks for sharing the link. I had not heard of Koka before.

Jan 06 2015
"Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Steven Schveighoffer"  wrote in message
news:m7sh3h$1co$1 digitalmars.com...
I think it wouldn't be a bad idea to investigate a new way to express
attributes, but I think no matter what we do, we need to rein in the
explosion of attributes that needs to be put on every function.

'\' is now free since we got rid of delimited strings.  We could start
introducing a new set of keywords starting with \ref until D looks like
latex.

Dec 29 2014
Walter Bright <newshound2 digitalmars.com> writes:
On 12/29/2014 9:39 PM, Daniel Murphy wrote:
'\' is now free since we got rid of delimited strings.  We could start
introducing a new set of keywords starting with \ref until D looks like latex.

It's already been done:

life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}

-- http://en.wikipedia.org/wiki/APL_(programming_language)#Examples

Dec 29 2014
"Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Monday, 29 December 2014 at 20:42:37 UTC, Dicebot wrote:
On Monday, 29 December 2014 at 20:20:45 UTC, Steven
Schveighoffer wrote:
But this precludes doing anything with a mutable t inside foo,
since inout means "const within the function".

Hm, yes, this is indeed quite the problem. I have totally
forgot that compiler has no means of figuring out which
invocation of inout is currently used.

But something very similar feels necessary to me. There is
constness, lifetime, purity - inventing new dedicated keyword
for each case does not feel like scaling approach. Especially
when existing one is named so generic.

I've been pondering this for a while, maybe someone with a better
theoretical foundation has an answer...

These concepts you mention (I'd add "type erasure", because
that's what inout is currently about) are inter-connected and
have some overlap with each other. But at the same time, they are
still separate concepts.

Do you think they are just aspects of one all-encompassing Grand
Unified Concept? Because if they turn out to be fundamentally
separate, they are better treated as such, instead of mixing them
up. Dedicated keywords may be the way to go if this is the case.
(From what I've seen so far, I think they are indeed separate,
but who knows?)

In general, I get the impression from both DIP25 and DIP69 that
both are motivated by minimizing the change to the existing
language, instead of looking for the most powerful solution (that
may have other use-cases besides the ones under consideration).
I.e., instead of asking which concepts are behind the problem in
question, how these concepts could be expressed in an ideal
world, and then making compromises to fit them into D, it seems
like we're starting with some premises (as few changes as
possible, no type modifiers), and then look for a solution that
needs to sacrifice the smallest number of use cases to stay
within the constraints. This is particularly bad if our premises
are going against the nature of the problem we want to solve,
because then we are guaranteed to get a bad solution.

Dec 30 2014
Walter Bright <newshound2 digitalmars.com> writes:
On 12/30/2014 1:27 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" wrote:
In general, I get the impression from both DIP25 and DIP69 that both are
motivated by minimizing the change to the existing language, instead of looking
for the most powerful solution (that may have other use-cases besides the ones
under consideration). I.e., instead of asking which concepts are behind the
problem in question, how these concepts could be expressed in an ideal world,
and then making compromises to fit them into D, it seems like we're starting
with some premises (as few changes as possible, no type modifiers), and then
look for a solution that needs to sacrifice the smallest number of use cases to
stay within the constraints. This is particularly bad if our premises are going
against the nature of the problem we want to solve, because then we are
guaranteed to get a bad solution.

On the other hand, power just because we can add it is not always a good thing.
C macros are very powerful, but experience has shown it is the wrong kind of
power. Also, programmers do not really want a complex annotation system. They
want to just write code in the most obvious manner and have it work correctly.
Having a powerful (but complex) system is not very attractive.

Dec 30 2014
Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 31 December 2014 at 10:09, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On 12/30/2014 1:27 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>"
wrote:
In general, I get the impression from both DIP25 and DIP69 that both are
motivated by minimizing the change to the existing language, instead of
looking
for the most powerful solution (that may have other use-cases besides the
ones
under consideration). I.e., instead of asking which concepts are behind
the
problem in question, how these concepts could be expressed in an ideal
world,
and then making compromises to fit them into D, it seems like we're
starting
with some premises (as few changes as possible, no type modifiers), and
then
look for a solution that needs to sacrifice the smallest number of use
cases to
stay within the constraints. This is particularly bad if our premises are
going
against the nature of the problem we want to solve, because then we are
guaranteed to get a bad solution.

On the other hand, power just because we can add it is not always a good
thing. C macros are very powerful, but experience has shown it is the wrong
kind of power. Also, programmers do not really want a complex annotation
system. They want to just write code in the most obvious manner and have it
work correctly. Having a powerful (but complex) system is not very
attractive.

His point is similar to my other point elsewhere though. I don't think
he's talking about 'power' in the sense you describe, what he's really
talking about is consistency or uniformity. His original scope
proposal wasn't 'powerful' (even though it was effectively more
powerful), it was holistic, and without the edges that seem to have
been introduced to try and 'contain the concept into a smaller space',
if that makes sense.

In this particular case, I think practical 'complexity' is being
expressed in the form of awkward edge cases, and the reason that
happened I suspect, is precisely what Andrei asked me to do; talk
about the specific problem case, not the general problem that's
recurring in numerous problem cases.
I feel like the current proposals are to effectively add yet more
edges to address specific cases, rather than removing the edges that
are already present causing the problems in the first place.
Address the problem, don't add layers of patches to round off rough edges.

Dec 30 2014
"Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Wednesday, 31 December 2014 at 03:25:24 UTC, Manu via
Digitalmars-d wrote:
On the other hand, power just because we can add it is not
always a good
thing. C macros are very powerful, but experience has shown it
is the wrong
kind of power. Also, programmers do not really want a complex
annotation
system. They want to just write code in the most obvious
manner and have it
work correctly. Having a powerful (but complex) system is not
very
attractive.

His point is similar to my other point elsewhere though. I
don't think
he's talking about 'power' in the sense you describe, what he's
really
talking about is consistency or uniformity. His original scope
proposal wasn't 'powerful' (even though it was effectively more
powerful), it was holistic, and without the edges that seem to
have
been introduced to try and 'contain the concept into a smaller
space',
if that makes sense.

In this particular case, I think practical 'complexity' is being
expressed in the form of awkward edge cases, and the reason that
happened I suspect, is precisely what Andrei asked me to do;
talk
about the specific problem case, not the general problem that's
recurring in numerous problem cases.
I feel like the current proposals are to effectively add yet
more
edges to address specific cases, rather than removing the edges
that
are already present causing the problems in the first place.
Address the problem, don't add layers of patches to round off
rough edges.

Thank you, I know what I wrote was kind of abstract, this
describes my thoughts quite well.

Dec 31 2014
"Dicebot" <public dicebot.lv> writes:
On Wednesday, 31 December 2014 at 03:25:24 UTC, Manu via
Digitalmars-d wrote:
His point is similar to my other point elsewhere though. I
don't think
he's talking about 'power' in the sense you describe, what he's
really
talking about is consistency or uniformity. His original scope
proposal wasn't 'powerful' (even though it was effectively more
powerful), it was holistic, and without the edges that seem to
have
been introduced to try and 'contain the concept into a smaller
space',
if that makes sense.

In this particular case, I think practical 'complexity' is being
expressed in the form of awkward edge cases, and the reason that
happened I suspect, is precisely what Andrei asked me to do;
talk
about the specific problem case, not the general problem that's
recurring in numerous problem cases.
I feel like the current proposals are to effectively add yet
more
edges to address specific cases, rather than removing the edges
that
are already present causing the problems in the first place.
Address the problem, don't add layers of patches to round off
rough edges.

This mostly matches my current opinion of DIP25 + DIP69 as well.
It is not as much problem of lacking power but utterly breaking
KISS principle - too many special cases to remember, too many
concepts to learn. Path of minimal necessary change is tempting
but it is path to C++.

Dec 31 2014
On Wednesday, 31 December 2014 at 21:08:29 UTC, Dicebot wrote:
This mostly matches my current opinion of DIP25 + DIP69 as
well. It is not as much problem of lacking power but utterly
breaking KISS principle - too many special cases to remember,
too many concepts to learn. Path of minimal necessary change is
tempting but it is path to C++.

Yes especially when this path create non orthogonal features,
which inevitably create a complexity explosion down the road.

This is the very old simple vs easy problem. Easy is tempting,
but simple is what we want and they sometime are very different
things.

Jan 05 2015
"Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Wednesday, 31 December 2014 at 00:09:15 UTC, Walter Bright
wrote:
On 12/30/2014 1:27 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?=
<schuetzm gmx.net>" wrote:
In general, I get the impression from both DIP25 and DIP69
that both are
motivated by minimizing the change to the existing language,
for the most powerful solution (that may have other use-cases
besides the ones
under consideration). I.e., instead of asking which concepts
are behind the
problem in question, how these concepts could be expressed in
an ideal world,
and then making compromises to fit them into D, it seems like
we're starting
with some premises (as few changes as possible, no type
modifiers), and then
look for a solution that needs to sacrifice the smallest
number of use cases to
stay within the constraints. This is particularly bad if our
premises are going
against the nature of the problem we want to solve, because
then we are
guaranteed to get a bad solution.

On the other hand, power just because we can add it is not
always a good thing. C macros are very powerful, but experience
has shown it is the wrong kind of power.

So... how does this apply to our problem concretely? Do you
believe a full blown ownership/lifetime system is "the wrong kind
of power"? Remember, we're talking about an ideal world at first.
If after thorough discussion it turns out that it can't be
integrated into D, at least we know that it's probably not
possible. But I haven't seen any indications that this is the
case; in fact, it's not even been discussed.

Also, programmers do not really want a complex annotation
system. They want to just write code in the most obvious manner
and have it work correctly. Having a powerful (but complex)
system is not very attractive.

But a powerful system doesn't need to be complicated. In fact, a
system with a handful of general and orthogonal features is
likely easier to understand and handle in practice than one with
lots of (even trivial) edge cases and exceptions.

Dec 31 2014
Walter Bright <newshound2 digitalmars.com> writes:
On 12/31/2014 3:23 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" wrote:
So... how does this apply to our problem concretely? Do you believe a full
blown
ownership/lifetime system is "the wrong kind of power"? Remember, we're talking
about an ideal world at first. If after thorough discussion it turns out that
it
can't be integrated into D, at least we know that it's probably not possible.
But I haven't seen any indications that this is the case; in fact, it's not
even
been discussed.

I don't believe it is impossible to implement in D, in fact, Bartosz Milewski
proposed such a system some years back. I do believe that people will simply
reject such a system as too hard to use.

(The reason dynamically typed languages are enduringly popular is that it is
easier to write code in them. People are inherently lazy. A full blown
lifetime/ownership system laid over a static type system would be an increase
in
programmer effort comparable to the gap between a dynamic and static type
system. I don't believe programmers will go for it.)

Also, programmers do not really want a complex annotation system. They want to
just write code in the most obvious manner and have it work correctly. Having
a powerful (but complex) system is not very attractive.

But a powerful system doesn't need to be complicated. In fact, a system with a
handful of general and orthogonal features is likely easier to understand and
handle in practice than one with lots of (even trivial) edge cases and
exceptions.

I agree that we all want that, but designing one that delivers such is another
matter entirely.

Programmers discover repeatedly that what is general, simple, and orthogonal
for
computers is grossly unintuitive and non-obvious for people. Successful user
interfaces are a mass of code implementing a mass of special cases.

Computer languages are user interfaces.

For a topical example, check out the threads here on the Ddoc syntax. Many have
strongly argued against the simple, general, powerful and orthogonal macro
syntax in favor of an idiosyncratic mass of special cases. It's classic.

Jan 02 2015
Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1/2/15, Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:
(The reason dynamically typed languages are enduringly popular is that it is
easier to write code in them. People are inherently lazy.)

Considering how much time one has to spend scratching their head what
type of a variable something is in Python, I think the *true slackers*
prefer statically typed languages. One hit of the compile button and
if it works you're 99% done already. :)

Jan 02 2015
Walter Bright <newshound2 digitalmars.com> writes:
On 1/2/2015 1:55 PM, Andrej Mitrovic via Digitalmars-d wrote:
Considering how much time one has to spend scratching their head what
type of a variable something is in Python, I think the *true slackers*
prefer statically typed languages. One hit of the compile button and
if it works you're 99% done already. :)

Yeah, but notice the growing popularity of 'auto'!

Jan 02 2015
Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1/2/15, Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:
On 1/2/2015 1:55 PM, Andrej Mitrovic via Digitalmars-d wrote:
Considering how much time one has to spend scratching their head what
type of a variable something is in Python, I think the *true slackers*
prefer statically typed languages. One hit of the compile button and
if it works you're 99% done already. :)

Yeah, but notice the growing popularity of 'auto'!

I used to use auto a lot in the past, and for some things I still do.
But I've come to really appreciate code readability, there could be
any number of people reading the code that I write in the future
(including me!). Knowing at a glance what type some variable is makes
it easier to understand code.

auto still kicks ass of course, especially for ranges and template code.

Jan 02 2015
Walter Bright <newshound2 digitalmars.com> writes:
On 1/2/2015 3:17 PM, Andrej Mitrovic via Digitalmars-d wrote:
auto still kicks ass of course, especially for ranges and template code.

Bluntly, auto makes those usable.

Jan 02 2015
Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1/3/15, Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:
On 1/2/2015 3:17 PM, Andrej Mitrovic via Digitalmars-d wrote:
auto still kicks ass of course, especially for ranges and template code.

Bluntly, auto makes those usable.

Yeah it shouldn't be looked upon as a gimmick, it's an enabler feature.

And let's not forget auto return types! (which I dearly miss in D1).

Jan 02 2015
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Jan 02, 2015 at 10:55:21PM +0100, Andrej Mitrovic via Digitalmars-d
wrote:
On 1/2/15, Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:
(The reason dynamically typed languages are enduringly popular is
that it is easier to write code in them. People are inherently
lazy.)

Considering how much time one has to spend scratching their head what
type of a variable something is in Python, I think the *true slackers*
prefer statically typed languages. One hit of the compile button and
if it works you're 99% done already. :)

Yeah, I think dynamically-typed languages lost a bit of their edge in
terms of catering to programmer laziness when statically-typed languages
started introducing type inference.

T

--
Don't modify spaghetti code unless you can eat the consequences.

Jan 02 2015
Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 02/01/15 22:16, Walter Bright via Digitalmars-d wrote:
I don't believe it is impossible to implement in D, in fact, Bartosz Milewski
proposed such a system some years back. I do believe that people will simply
reject such a system as too hard to use.

Isn't that dependent on the use-case, though?  We know very well that games
programmers (for example) will jump through programming fire, compared to many
other developers, in order to achieve their desired results.

Assuming that we're not going to lose the default case of the GC being
responsible for allocation/ownership unless the programmer specifies otherwise,
what's wrong with having a rigorous ownership system in place that can be made
use of if and only if the programmer sees value in it?

For a topical example, check out the threads here on the Ddoc syntax. Many have
strongly argued against the simple, general, powerful and orthogonal macro
syntax in favor of an idiosyncratic mass of special cases. It's classic.

OK, tongue in cheek time, but if simple, powerful and orthogonal is the goal,
why are we messing around with this D stuff instead of just writing everything
in Lisp? ;-)

I hope it's obvious what I'm getting at here -- a really simple, general and
powerful syntax can become horrendously complicated to deal with once you start
going beyond a certain scale of combinations.

Jan 02 2015
Walter Bright <newshound2 digitalmars.com> writes:
On 1/2/2015 2:38 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
On 02/01/15 22:16, Walter Bright via Digitalmars-d wrote:
I don't believe it is impossible to implement in D, in fact, Bartosz Milewski
proposed such a system some years back. I do believe that people will simply
reject such a system as too hard to use.

Isn't that dependent on the use-case, though?  We know very well that games
programmers (for example) will jump through programming fire, compared to many
other developers, in order to achieve their desired results.

Take a look at noted game developer Jonathan Blow's videos. They'll jump
through
hoops for performance, but I see little evidence they will do so for
correctness. It's like have a nun stand over you and rap your knuckles every
time your handwriting isn't perfect. Nobody likes that.

Assuming that we're not going to lose the default case of the GC being
responsible for allocation/ownership unless the programmer specifies otherwise,
what's wrong with having a rigorous ownership system in place that can be made
use of if and only if the programmer sees value in it?

Because of the viral nature of it, you cannot avoid it. It's like trying to
avoid using const.

For a topical example, check out the threads here on the Ddoc syntax. Many have
strongly argued against the simple, general, powerful and orthogonal macro
syntax in favor of an idiosyncratic mass of special cases. It's classic.

OK, tongue in cheek time, but if simple, powerful and orthogonal is the goal,
why are we messing around with this D stuff instead of just writing everything
in Lisp? ;-)

Exactly.

I hope it's obvious what I'm getting at here -- a really simple, general and
powerful syntax can become horrendously complicated to deal with once you start
going beyond a certain scale of combinations.

Don't I know it :-)

Jan 02 2015
Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 3 January 2015 at 10:07, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On 1/2/2015 2:38 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
On 02/01/15 22:16, Walter Bright via Digitalmars-d wrote:
I don't believe it is impossible to implement in D, in fact, Bartosz
Milewski
proposed such a system some years back. I do believe that people will
simply
reject such a system as too hard to use.

Isn't that dependent on the use-case, though?  We know very well that
games
programmers (for example) will jump through programming fire, compared to
many
other developers, in order to achieve their desired results.

Take a look at noted game developer Jonathan Blow's videos. They'll jump
through hoops for performance, but I see little evidence they will do so for
correctness. It's like have a nun stand over you and rap your knuckles every
time your handwriting isn't perfect. Nobody likes that.

I feel like your resistance of comprehensive scope is some part
emotional, some part anecdotal... but little or not parts
experimentally based.
You appear to 'fear' what it would do... and maybe you have the
experience to judge that better than me, but I just can't see it!

Assuming that we're not going to lose the default case of the GC being
responsible for allocation/ownership unless the programmer specifies
otherwise,
what's wrong with having a rigorous ownership system in place that can be
use of if and only if the programmer sees value in it?

Because of the viral nature of it, you cannot avoid it. It's like trying to
avoid using const.

scope isn't like const though, it's a different thing. I think you're
just trying to incite FUD with that particular comparison.
It doesn't inhibit interoperation of data the same way as const does.
It only inhibits interoperation in the case of escaping local data to
the outside world.
Cases where we currently allow that (because the tech we have is
insufficient to detect the cases) are probably bugs. They violate D's
safety guarantees, and that's a core commitment of D.
I don't think we can ever really make good on the  safe commitment
without scope/lifetime. So from that perspective, we either need to
take scope seriously, or stop advertising that we take safety
seriously.

In practise, I suspect it would be more like pure or nothrow in its
impact. How many hours do you spend wrangling pure or nothrow issues
compared to const issues?
I can say that pure/nothrow barely ever cause me any trouble, and when
they do, I'm often surprised that they actually reveal what would have
been a bug.

An awful lot of the modern big-ticket problems in software engineering
are relating to ownership.

I hope it's obvious what I'm getting at here -- a really simple, general
and
powerful syntax can become horrendously complicated to deal with once you
start
going beyond a certain scale of combinations.

Don't I know it :-)

We're already there though. And to resist one more with very
significant importance is drawing an arbitrary line. You got behind
nogc fairly recently with no particular friction...
We already know we have to get better at attribute inference, that's
critical to addressing the situation we are already in. Assuming we
succeed with that (we must, and it's not a particularly hard problem
anyway), then that solution applies equally for this case too.

But if we have drawn a hard line in terms of quantity of attributes, I
would gladly sacrifice  nogc, or nothrow in favour of scope.

Jan 02 2015
Walter Bright <newshound2 digitalmars.com> writes:
On 1/2/2015 9:27 PM, Manu via Digitalmars-d wrote:
I feel like your resistance of comprehensive scope is some part
emotional, some part anecdotal... but little or not parts
experimentally based.
You appear to 'fear' what it would do... and maybe you have the
experience to judge that better than me, but I just can't see it!

Hardly anyone understood DIP69, and that one is very simple compared to a
comprehensive ownership system.

Because of the viral nature of it, you cannot avoid it. It's like trying to
avoid using const.

scope isn't like const though, it's a different thing. I think you're
just trying to incite FUD with that particular comparison.
It doesn't inhibit interoperation of data the same way as const does.
It only inhibits interoperation in the case of escaping local data to
the outside world.

That's a lot of handwaving.

Cases where we currently allow that (because the tech we have is
insufficient to detect the cases) are probably bugs. They violate D's
safety guarantees, and that's a core commitment of D.
I don't think we can ever really make good on the  safe commitment
without scope/lifetime. So from that perspective, we either need to
take scope seriously, or stop advertising that we take safety
seriously.

DIP25 and 69 make it safe.

We're already there though. And to resist one more with very
significant importance is drawing an arbitrary line.

Propose a design. I suggest, though, that if it was half as easy as you say, it
would already exist in multiple languages. It's not like nobody thought of it
before.

"Maybe some track lighting will help!"


Jan 03 2015
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 3 January 2015 at 08:41:44 UTC, Walter Bright wrote:
On 1/2/2015 9:27 PM, Manu via Digitalmars-d wrote:
I feel like your resistance of comprehensive scope is some part
emotional, some part anecdotal... but little or not parts
experimentally based.
You appear to 'fear' what it would do... and maybe you have the
experience to judge that better than me, but I just can't see
it!

Hardly anyone understood DIP69, and that one is very simple
compared to a comprehensive ownership system.

Does this mean that D is not going to get a comprehensive
ownership system in a later edition (like D3)?

Because if that is not on the roadmap then I think you need to
spend a lot more effort on getting an efficient precise GC if you
want D to survive.

Propose a design. I suggest, though, that if it was half as
easy as you say, it would already exist in multiple languages.
It's not like nobody thought of it before.

How about making all functions that take references/pointers
templates and define protocols for relaying information to the
compiler? I know Manu will hate that, but are you against it?

Jan 03 2015
Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 3 January 2015 at 18:41, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On 1/2/2015 9:27 PM, Manu via Digitalmars-d wrote:
I feel like your resistance of comprehensive scope is some part
emotional, some part anecdotal... but little or not parts
experimentally based.
You appear to 'fear' what it would do... and maybe you have the
experience to judge that better than me, but I just can't see it!

Hardly anyone understood DIP69, and that one is very simple compared to a
comprehensive ownership system.

I didn't understand it because the approach didn't make sense to me.
It appeared to exhibit a whole lot of edge cases, and addressed
relatively few of the cases I care about.
The fact that it seemed so problematic lead me to presume that I
simply didn't understand it, rather than that it was actually as
problematic as it appeared.

Marc's proposal on the other hand made perfect sense to me. I don't
think anybody misunderstood Marc's proposal... why is that?

Because of the viral nature of it, you cannot avoid it. It's like trying
to
avoid using const.

scope isn't like const though, it's a different thing. I think you're
just trying to incite FUD with that particular comparison.
It doesn't inhibit interoperation of data the same way as const does.
It only inhibits interoperation in the case of escaping local data to
the outside world.

That's a lot of handwaving.

That's my point!

Are you saying const was a mistake? Should we be trying to avoid using
const? And use that as justification against in this case?

Cases where we currently allow that (because the tech we have is
insufficient to detect the cases) are probably bugs. They violate D's
safety guarantees, and that's a core commitment of D.
I don't think we can ever really make good on the  safe commitment
without scope/lifetime. So from that perspective, we either need to
take scope seriously, or stop advertising that we take safety
seriously.

DIP25 and 69 make it safe.

Perhaps, and they might address a problem here, but they just compound
the other problems in the language that I'm already the most critical
of.

I have come to oppose storage class absolutely. It has taken me half a
decade to get there, so don't tell me I didn't try to love it (I
really thought it was a good idea at first!).
The problem is, it doesn't fit in D. I can't support any further
commitment to that failed design.
storage class == frustration, text mixins, and code duplication. Those
are really bad things.

I'm more frustrated by storage class than I am about echoing an rvalue
to a stupidly named temporary on the stack so I can pass it to a
function (which I am also extremely frustrated with).
I really need a good RC implementation, but I don't think we should be
making this sort of compromise for it.
Microsoft's C++/CX approach of "int ^rcPointer;" looks really elegant
to me by contrast.

It's like this: ref is a massive problem when it finds it's way into meta.
ref is relatively rare today... so the problem is occasional.
scope on the other hand will be epic compared to ref. If we infer
scope (which we'll probably need to), chances are, the vast majority
of functions will involve scope.
We can't have the trouble with ref (read: trouble with 'storage
class') applied to the majority of functions.

We're already there though. And to resist one more with very
significant importance is drawing an arbitrary line.

Propose a design. I suggest, though, that if it was half as easy as you say,
it would already exist in multiple languages. It's not like nobody thought
of it before.

It's a relatively new hot-topic problem, and it exists in Rust; it's
basically the whole point of the language as far as I can tell.
Also, most modern languages aren't strongly typed, so it's an
irrelevant problem for most.

I was firmly in support of Marc's design. I'm not sure why it was rejected.
What were the problems? Why did it become a storage class, other than
because of fear that it might pervade too deeply if it were part of
the type?

"Maybe some track lighting will help!"

--

Umm, I don't understand?

Jan 03 2015
Walter Bright <newshound2 digitalmars.com> writes:
On 1/3/2015 5:12 PM, Manu via Digitalmars-d wrote:
Are you saying const was a mistake? Should we be trying to avoid using
const? And use that as justification against in this case?

const to me suggested a limit on what we can do in pushing annotations on
people. It is also quite simple in concept.

I was firmly in support of Marc's design. I'm not sure why it was rejected.
What were the problems? Why did it become a storage class, other than
because of fear that it might pervade too deeply if it were part of
the type?

It will pervade deeply if it was part of the type.

"Maybe some track lighting will help!"

--

Umm, I don't understand?

Bob Vila's flip answer, as if nobody thought of adding lights to better light
up
a dark room.

Jan 03 2015
Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 4 January 2015 at 13:34, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On 1/3/2015 5:12 PM, Manu via Digitalmars-d wrote:

I was firmly in support of Marc's design. I'm not sure why it was
rejected.
What were the problems? Why did it become a storage class, other than
because of fear that it might pervade too deeply if it were part of
the type?

It will pervade deeply if it was part of the type.

Right, and that's the entire point.
Are there problems with that, or just fear of the scope of the change?

I don't see how an effort to keep this confined within a small box
such that it doesn't pervade can ever result in orthogonal behaviour.
It's too important a concept, and it will appear everywhere, in all
kinds of situations. Much more than ref I'm sure.
Any time the concept finds itself bleeding outside it's little box,
the problems will be awkward and practically unmanageable.

Jan 03 2015
Walter Bright <newshound2 digitalmars.com> writes:
On 1/3/2015 5:12 PM, Manu via Digitalmars-d wrote:
I was firmly in support of Marc's design. I'm not sure why it was rejected.
What were the problems? Why did it become a storage class, other than
because of fear that it might pervade too deeply if it were part of
the type?

I felt unaddressed what are the interactions with other scope qualifiers, how
type deduction works, how would auto work, covariance, how are types like

int****scope(foo)****

handled, how would generic code get written that used this, name mangling, auto
returns, etc. A comprehensive spec for it would be much larger. I tried to do a
more comprehensive spec with DIP69, and it wound giving the impression that it
was more complex when it was actually simpler. I'm also painfully aware of how
'simple' C++'s ref appeared and how awful it is in practice.

And lastly, I thought it verbose, such as:

scope!haystack(string) findSubstring(scope(string) haystack, scope(string)
needle);

There have been many complaints, including from you, about the existing
verbosity of function declarations.

Jan 03 2015
"tobias pankrath.net" <tobias pankrath.net> writes:
 It's like this: ref is a massive problem when it finds it's way
into meta.
ref is relatively rare today... so the problem is occasional.
scope on the other hand will be epic compared to ref. If we
infer
scope (which we'll probably need to), chances are, the vast
majority
of functions will involve scope.
We can't have the trouble with ref (read: trouble with 'storage
class') applied to the majority of functions.

I thought most of your problems stem from 'auto ref' and not from
ref? If scope does not affect the overload set, I don't see how
you could get into trouble with meta programming using it. Could

Jan 04 2015
"Zach the Mystic" <reachzach gggmail.com> writes:
On Sunday, 4 January 2015 at 01:12:14 UTC, Manu via Digitalmars-d
wrote:
It's like this: ref is a massive problem when it finds it's way
into meta.
ref is relatively rare today... so the problem is occasional.
scope on the other hand will be epic compared to ref. If we
infer
scope (which we'll probably need to), chances are, the vast
majority
of functions will involve scope.
We can't have the trouble with ref (read: trouble with 'storage
class') applied to the majority of functions.

Hey Manu, I think it would still be a good idea to provide code
examples of your points right in the forums. I was able to look
at the file from luaD and see how the problems were occurring,
but it would hasten my understanding just to see several 'reduced
test cases' of that example and others, if possible.

Jan 05 2015