www.digitalmars.com         C & C++   DMDScript  

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

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

Please comment: http://wiki.dlang.org/DIP25


Thanks,

Andrei
Dec 27 2014
next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Sunday, 28 December 2014 at 03:09:20 UTC, Andrei Alexandrescu 
wrote:
 Please comment: http://wiki.dlang.org/DIP25
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
parent reply 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:
 Please comment: http://wiki.dlang.org/DIP25
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
next sibling parent reply "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 
 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?
 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
next sibling parent reply 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
next sibling parent 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
prev sibling parent reply 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
 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.
I'm not sure what you mean by this, but inout as a type modifier is definitely transitive. -Steve
Dec 29 2014
parent reply 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
parent reply 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
parent reply "deadalnix" <deadalnix gmail.com> writes:
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. -Steve
On the other hand, inout IS a disaster, so why not ?
Jan 05 2015
parent reply 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
next sibling parent reply "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 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
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
parent reply 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
parent reply "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
parent 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
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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
parent reply 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
parent "deadalnix" <deadalnix gmail.com> writes:
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
prev sibling parent reply 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
 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?
Not even those for the most part. The archetypal higher order range: struct Wrapper(R) { private R payload; ref ElementType!R front() { return payload.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
parent 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
prev sibling parent "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
prev sibling next sibling parent reply 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.

 Please comment: http://wiki.dlang.org/DIP25
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
parent 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.

 Please comment: http://wiki.dlang.org/DIP25
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
prev sibling next sibling parent reply 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
parent 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
prev sibling next sibling parent reply "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.

 Please comment: http://wiki.dlang.org/DIP25


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

 Please comment: http://wiki.dlang.org/DIP25


 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
prev sibling next sibling parent reply "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.

 Please comment: http://wiki.dlang.org/DIP25


 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
parent 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
prev sibling next sibling parent reply 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.

 Please comment: http://wiki.dlang.org/DIP25


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

 Please comment: http://wiki.dlang.org/DIP25


 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
next sibling parent 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
prev sibling next sibling parent reply "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
parent reply 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
parent reply 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
parent reply 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.
I think you are wrong about this. Andrei
Dec 30 2014
parent reply 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.
I think you are wrong about this.
In what way? I don't see why exploring a more fundamental solution is absolutely off the table.
Dec 30 2014
next sibling parent reply 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
parent reply 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
parent 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
prev sibling parent reply 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
next sibling parent reply 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
parent reply "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
parent 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 `out`s, 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
prev sibling next sibling parent 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
prev sibling next sibling parent reply 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
parent reply 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
parent 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
prev sibling parent "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 problems during multithreading. 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
prev sibling next sibling parent "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
prev sibling next sibling parent reply 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.

 Please comment: http://wiki.dlang.org/DIP25


 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
parent 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
prev sibling next sibling parent reply 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
parent reply 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] Good stuff, thanks. Question about this:
 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
next sibling parent "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
prev sibling next sibling parent 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] Good stuff, thanks. Question about this: 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
prev sibling parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 02/01/15 10:26, Andrei Alexandrescu via Digitalmars-d wrote:
 Good stuff, thanks. Question about this:
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.
Jan 02 2015
next sibling parent reply 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
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.
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
next sibling parent "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
prev sibling parent reply 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
next sibling parent 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
prev sibling next sibling parent reply 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
parent reply 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
parent 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
prev sibling parent reply "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
parent 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
prev sibling parent 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:
 Good stuff, thanks. Question about this:
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
prev sibling parent 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
prev sibling parent reply 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.

 Please comment: http://wiki.dlang.org/DIP25
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
parent reply 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.

 Please comment: http://wiki.dlang.org/DIP25
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
parent reply 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.

 Please comment: http://wiki.dlang.org/DIP25
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
parent reply 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.

 Please comment: http://wiki.dlang.org/DIP25
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
parent reply "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
parent reply 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
parent reply "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
parent reply 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
parent reply "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
next sibling parent reply 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
next sibling parent "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
prev sibling next sibling parent reply 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
parent reply 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 linker... 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
next sibling parent 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
prev sibling parent reply 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
parent reply 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 readable/maintainable code. 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
next sibling parent reply 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
 readable/maintainable code.

 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
next sibling parent 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
 readable/maintainable code.

 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
prev sibling parent "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
prev sibling parent reply "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
parent reply "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
next sibling parent "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
prev sibling parent "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
prev sibling parent reply "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
parent 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
prev sibling parent reply "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
parent reply 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
next sibling parent reply 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
next sibling parent "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
prev sibling parent reply "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
parent "deadalnix" <deadalnix gmail.com> writes:
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
prev sibling parent reply "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, 
 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.
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
parent reply 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
next sibling parent reply 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
parent reply 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
parent reply 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
parent reply 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
parent 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
prev sibling next sibling parent "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
prev sibling parent reply 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
parent reply 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
parent reply 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
 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.
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
parent reply 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!" -- https://www.youtube.com/watch?feature=player_detailpage&v=P9FHlhWqbus#t=17
Jan 03 2015
next sibling parent "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
prev sibling parent reply 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!"

   --
 https://www.youtube.com/watch?feature=player_detailpage&v=P9FHlhWqbus#t=17
Umm, I don't understand?
Jan 03 2015
next sibling parent reply 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!"

    --
 https://www.youtube.com/watch?feature=player_detailpage&v=P9FHlhWqbus#t=17
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
parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent "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 you please clarify?
Jan 04 2015
prev sibling parent "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