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