Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/18/2015 8:34 AM, Andrei Alexandrescu wrote: On 1/18/15 5:44 AM, Jacob Carlborg wrote: On 2015-01-17 18:43, Andrei Alexandrescu wrote: I'm the author so I'm waiting for comments from the others, not prone to commenting on my own proposal. --- Andrei I'm not sure who made the proposal but Walter created the pull request. Walter and I made the proposal. Could you explain exactly what your problem is. It's also based on Marc Schütz's earlier proposal.
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 2015-01-17 18:43, Andrei Alexandrescu wrote: I'm the author so I'm waiting for comments from the others, not prone to commenting on my own proposal. --- Andrei I'm not sure who made the proposal but Walter created the pull request. -- /Jacob Carlborg
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/17/2015 7:38 PM, Jonathan M Davis via Digitalmars-d wrote: I am a bit surprised though that you agreed to it given that in previous discussions you seemed opposed to adding any more attributes for parameters. It does make for a fairly straightforward solution though. Your last sentence explains it. The 'return ref' with deduction also appears to cause the fewest changes to existing code.
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/18/15 5:44 AM, Jacob Carlborg wrote: On 2015-01-17 18:43, Andrei Alexandrescu wrote: I'm the author so I'm waiting for comments from the others, not prone to commenting on my own proposal. --- Andrei I'm not sure who made the proposal but Walter created the pull request. Walter and I made the proposal. Could you explain exactly what your problem is. -- Andrei
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On Friday, 16 January 2015 at 21:55:13 UTC, Zach the Mystic wrote: I'm working on an article/DIP which actually goes further than the new DIP25, but is nonetheless completely compatible with it. I'll have the article in a day or two. Here it is: http://forum.dlang.org/thread/xjhvpmjrlwhhgeqyo...@forum.dlang.org
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On Saturday, 17 January 2015 at 21:21:05 UTC, Walter Bright wrote: On 1/17/2015 4:40 AM, Manu via Digitalmars-d wrote: So when handling ref-related edge cases, do we now have to handle 3 cases? not-ref, ref, and return-ref right? How do I know if some argument is return-ref? I guess we'll need another annoying __traits or something so I can pipe that information into my mixins that deal with ref mess... Or have your mixins generate templates, which will infer 'return'. On that ref issue, I just have to duplicate a bunch of code so it can work for classes and struct alike. There is no way to make something conditionally ref.
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu wrote: Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 Andrei Congratulations to all, I like it, now: It's for sure an appreciated step forward! yay! --- /Paolo
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 2015-01-17 00:01, Andrei Alexandrescu wrote: On 1/16/15 2:52 PM, Daniel Kozak wrote: P.S. I like this DIP, but I do not like way how things are done :( Please participate to improving how things are done. How can we do that when you're just saying things like Time to move forward, it's a judgement call, lets do it and then just merges Walter's pull requests? -- /Jacob Carlborg
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 17 January 2015 at 07:41, Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 Andrei So when handling ref-related edge cases, do we now have to handle 3 cases? not-ref, ref, and return-ref right? How do I know if some argument is return-ref? I guess we'll need another annoying __traits or something so I can pipe that information into my mixins that deal with ref mess...
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On Saturday, 17 January 2015 at 01:51:25 UTC, Steven
Schveighoffer wrote:
On 1/16/15 8:18 PM, Andrei Alexandrescu wrote:
On 1/16/15 4:56 PM, Steven Schveighoffer wrote:
On 1/16/15 6:01 PM, Andrei Alexandrescu wrote:
On 1/16/15 2:52 PM, Daniel Kozak wrote:
Why DIP says: Last Modified: 2015-01-11
but from history I see lots of changing after that date?
I wish that were automated.
Well, it does include last modified automatically at the
bottom of the
page. Is it worth keeping that manual entry?
I tried to see if there was a way to reference that, but it's
not
possible from what I can tell.
Then I'd say just yank it. Apparently you can with an
extension:
http://www.mediawiki.org/wiki/Extension:LastModified
I figured it out, thanks in part to your link :)
{{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY}}
They HAVE to be capitalized (that took me a while to figure
out).
That's not necessarily a good change. The date should reflect
only when the actual content changes, but not e.g. when someone
adds a category, and probably neither for small changes like a
fixed typo.
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On Friday, 16 January 2015 at 21:55:13 UTC, Zach the Mystic wrote: On Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu wrote: Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 Andrei I'm working on an article/DIP which actually goes further than the new DIP25, but is nonetheless completely compatible with it. I'll have the article in a day or two. I'm very interested in that! I think the `return` notation is a good idea, and can maybe be reused in a more complete `scope` proposal. A downside is that it only applies to the return value, but not to other `out` and `ref` parameters. But the `!` syntax can work here, too.
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/17/15 4:40 AM, Manu via Digitalmars-d wrote: I guess we'll need another annoying __traits or something so I can pipe that information into my mixins that deal with ref mess... Yes. -- Andrei
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/17/15 3:56 AM, Jacob Carlborg wrote: On 2015-01-17 00:01, Andrei Alexandrescu wrote: On 1/16/15 2:52 PM, Daniel Kozak wrote: P.S. I like this DIP, but I do not like way how things are done :( Please participate to improving how things are done. How can we do that when you're just saying things like Time to move forward, it's a judgement call, lets do it and then just merges Walter's pull requests? I'm the author so I'm waiting for comments from the others, not prone to commenting on my own proposal. --- Andrei
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On Saturday, 17 January 2015 at 17:08:42 UTC, Marc Schütz wrote: On Friday, 16 January 2015 at 21:55:13 UTC, Zach the Mystic I'm working on an article/DIP which actually goes further than the new DIP25, but is nonetheless completely compatible with it. I'll have the article in a day or two. I'm very interested in that! I think the `return` notation is a good idea, and can maybe be reused in a more complete `scope` proposal. A downside is that it only applies to the return value, but not to other `out` and `ref` parameters. But the `!` syntax can work here, too. Yup. In fact, my DIP is partly inspired the 'scope!' syntax suggestion in your DIP.
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu wrote: Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 Andrei It seems to me that once this DIP is implemented, it should be safe to allow taking an rvalue by reference in safe code as long as it is not annotated with `return`. Is this correct?
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/17/2015 4:40 AM, Manu via Digitalmars-d wrote: So when handling ref-related edge cases, do we now have to handle 3 cases? not-ref, ref, and return-ref right? How do I know if some argument is return-ref? I guess we'll need another annoying __traits or something so I can pipe that information into my mixins that deal with ref mess... Or have your mixins generate templates, which will infer 'return'.
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On Friday, January 16, 2015 13:41:24 Andrei Alexandrescu via Digitalmars-d
wrote:
Please help us work the kinks out! Walter will be proceeding with the
opt-in implementation for quicker pipelining.
http://wiki.dlang.org/DIP25
I would point out that the Deduction section has code that won't even
compile, because it uses auto ref on a non-templated function:
auto ref T identity(auto ref T) {
return x; // correct, no need for return
}
I assume that that should be something more like
auto ref T identity(T)(auto ref T) {
return x; // correct, no need for return
}
Or am I misunderstanding the intent of the example? I can certainly fix the
page myself, but I don't want to change it in an incorrect manner, and it's
not my DIP.
In any case, while I haven't been as active on the newsgroup lately as I'd
like and missed all of the previous discussions on this, the DIP doesn't
seem like a bad solution. I am a bit surprised though that you agreed to it
given that in previous discussions you seemed opposed to adding any more
attributes for parameters. It does make for a fairly straightforward
solution though.
- Jonathan M Davis
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 18 January 2015 at 07:20, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 1/17/2015 4:40 AM, Manu via Digitalmars-d wrote: So when handling ref-related edge cases, do we now have to handle 3 cases? not-ref, ref, and return-ref right? How do I know if some argument is return-ref? I guess we'll need another annoying __traits or something so I can pipe that information into my mixins that deal with ref mess... Or have your mixins generate templates, which will infer 'return'. *sigh* Don't get me started on auto-ref again. We'll need some sort of traits to detect the return-ref case.
http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 Andrei
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu wrote: Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 Andrei I'm working on an article/DIP which actually goes further than the new DIP25, but is nonetheless completely compatible with it. I'll have the article in a day or two.
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu wrote: Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 Andrei I added support to my tools a few days ago: https://github.com/Hackerpilot/libdparse/commit/fc9dacfa41c0bae258814ad64e58ffaae6b961cc Now I need to make a pull request that updates the official grammar...
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/16/2015 1:41 PM, Andrei Alexandrescu wrote: Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 https://github.com/D-Programming-Language/dmd/pull/4298
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/16/15 4:41 PM, Andrei Alexandrescu wrote: Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 I was about to complain because I remember not liking that DIP, but I see you removed inout as the notation, opting for return instead. Looks good now! One thing I would note: in Types of Result vs. Parameters, I think it should stay this way. Simple explanation is: IFTI/auto returns. We have a very similar situation with inout. Originally, I insisted that inout only was valid on a parameter if it was also designated on the return. This kind of makes sense. But it caused issues with templates, because inout could be deduced by IFTI, and then it wasn't on the return. We have now fixed the compiler so inout reduces to const if not specified on the return. I can potentially see a situation like this: auto fun(T)(return ref T x) Where the auto deduces to something that couldn't possibly match T or any piece of it. Causing this function to error just because of a type mismatch is the wrong move. -Steve
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/16/15 2:00 PM, Brian Schott wrote: On Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu wrote: Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 Andrei I added support to my tools a few days ago: https://github.com/Hackerpilot/libdparse/commit/fc9dacfa41c0bae258814ad64e58ffaae6b961cc Now I need to make a pull request that updates the official grammar... Fantastic. Walter has a pull for the parser already. Please don't forget the feature is opt-in. -- Andrei
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu wrote: Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 Andrei Some questions What is purpose of DIPs? Who can approve them? How can something been preliminarily approved without any discussion? Why DIP says: Last Modified: 2015-01-11 but from history I see lots of changing after that date? P.S. I like this DIP, but I do not like way how things are done :(
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/16/15 5:52 PM, Daniel Kozak wrote: On Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu wrote: Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 Andrei Some questions What is purpose of DIPs? To have a more formal place to put a proposal for a major D language improvement. Who can approve them? Ultimately, Walter. How can something been preliminarily approved without any discussion? Much discussion has happened on this. e.g.: http://forum.dlang.org/post/m7ns90$16t1$1...@digitalmars.com http://forum.dlang.org/post/ket199$2c27$1...@digitalmars.com Why DIP says: Last Modified: 2015-01-11 but from history I see lots of changing after that date? That date is manually entered. I'll fix it. -Steve
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/16/15 2:52 PM, Daniel Kozak wrote: On Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu wrote: Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 Andrei Some questions What is purpose of DIPs? To improve D :o). DIP = D Improvement Proposal. Who can approve them? Walter and I. How can something been preliminarily approved without any discussion? There's been quite a bit of it, and we listened to it - we changed inout to return. This has been public for a good time and is important AND urgent while much debate has been carried on inconsequential topics. Time to move forward. Why DIP says: Last Modified: 2015-01-11 but from history I see lots of changing after that date? I wish that were automated. P.S. I like this DIP, but I do not like way how things are done :( Please participate to improving how things are done. Andrei
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
Steven Schveighoffer via Digitalmars-d píše v Pá 16. 01. 2015 v 17:59 -0500: On 1/16/15 5:52 PM, Daniel Kozak wrote: On Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu wrote: Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 Andrei Some questions What is purpose of DIPs? To have a more formal place to put a proposal for a major D language improvement. Who can approve them? Ultimately, Walter. How can something been preliminarily approved without any discussion? Much discussion has happened on this. e.g.: http://forum.dlang.org/post/m7ns90$16t1$1...@digitalmars.com http://forum.dlang.org/post/ket199$2c27$1...@digitalmars.com Oh I see, I miss it Why DIP says: Last Modified: 2015-01-11 but from history I see lots of changing after that date? That date is manually entered. I'll fix it. -Steve Thanks
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 16.01.15 22:41, Andrei Alexandrescu wrote: Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 Andrei Why is it restricted to @safe?
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/16/2015 2:13 PM, Steven Schveighoffer wrote: I can potentially see a situation like this: auto fun(T)(return ref T x) Where the auto deduces to something that couldn't possibly match T or any piece of it. Causing this function to error just because of a type mismatch is the wrong move. That is addressed by the DIP, it is specifically allowed that a 'return ref' can be used even when the pointer cannot be coerced into the returned ref. This is so that the 'return ref' can refer to a container that completely owns its contents, and this ownership can thus be transferred to the output.
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/16/15 6:10 PM, zeljkog wrote: On 16.01.15 22:41, Andrei Alexandrescu wrote: Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 Andrei Why is it restricted to @safe? I don't think it is, the numerous @safe tags are superfluous. Andrei/Walter should clarify this... -Steve
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/16/2015 3:10 PM, zeljkog wrote: Why is it restricted to @safe? Being a systems programming language, an escape from it may be necessary.
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
Walter Bright: On 1/16/2015 3:10 PM, zeljkog wrote: Why is it restricted to @safe? Being a systems programming language, an escape from it may be necessary. But this DIP to have a meaning should go with a @safe by default, I think. Bye, bearophile
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu wrote: Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 Andrei I prefer the new syntax, this is a good change. Is this DIP replacing DIP69?
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/16/15 3:10 PM, zeljkog wrote: On 16.01.15 22:41, Andrei Alexandrescu wrote: Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 Andrei Why is it restricted to @safe? To avoid some of the code breakage. -- Andrei
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/16/15 6:25 PM, Walter Bright wrote:
On 1/16/2015 3:10 PM, zeljkog wrote:
Why is it restricted to @safe?
Being a systems programming language, an escape from it may be necessary.
So:
ref int foo(ref int x) { return x; }
is OK as long as it's not marked @safe? Is this made clear in the DIP? I
didn't see that. In fact @safe is never mentioned except in the code
examples. Even in the inline text examples, it's not mentioned.
In at least one place, it's implied that the above would not compile
under the DIP: With the proposed semantics, a function is disallowed to
return a ref parameter of a part thereof UNLESS the parameter is also
annotated with return.
-Steve
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/16/15 3:45 PM, weaselcat wrote: On Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu wrote: Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 Andrei I prefer the new syntax, this is a good change. Is this DIP replacing DIP69? No, it's a gateway drug. -- Andrei
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/16/15 3:55 PM, Steven Schveighoffer wrote:
On 1/16/15 6:25 PM, Walter Bright wrote:
On 1/16/2015 3:10 PM, zeljkog wrote:
Why is it restricted to @safe?
Being a systems programming language, an escape from it may be necessary.
So:
ref int foo(ref int x) { return x; }
is OK as long as it's not marked @safe? Is this made clear in the DIP? I
didn't see that. In fact @safe is never mentioned except in the code
examples. Even in the inline text examples, it's not mentioned.
In at least one place, it's implied that the above would not compile
under the DIP: With the proposed semantics, a function is disallowed to
return a ref parameter of a part thereof UNLESS the parameter is also
annotated with return.
-Steve
The DIP applies to @safe code only for now. Steve, could you please add
a clarifying section. Thanks! -- Andrei
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/16/15 7:14 PM, Andrei Alexandrescu wrote: The DIP applies to @safe code only for now. Steve, could you please add a clarifying section. Thanks! -- Andrei OK, done. Please review. -Steve
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On Saturday, 17 January 2015 at 00:14:47 UTC, Andrei Alexandrescu
wrote:
On 1/16/15 3:55 PM, Steven Schveighoffer wrote:
On 1/16/15 6:25 PM, Walter Bright wrote:
On 1/16/2015 3:10 PM, zeljkog wrote:
Why is it restricted to @safe?
Being a systems programming language, an escape from it may
be necessary.
So:
ref int foo(ref int x) { return x; }
is OK as long as it's not marked @safe? Is this made clear in
the DIP? I
didn't see that. In fact @safe is never mentioned except in
the code
examples. Even in the inline text examples, it's not mentioned.
In at least one place, it's implied that the above would not
compile
under the DIP: With the proposed semantics, a function is
disallowed to
return a ref parameter of a part thereof UNLESS the parameter
is also
annotated with return.
-Steve
The DIP applies to @safe code only for now. Steve, could you
please add a clarifying section. Thanks! -- Andrei
Overall I like this improvement. I think the change to `return`
is good, keeps things clear; at least I had difficulty keeping
the various usages clear (didn't have time to comment in the
thread). Thanks for that. Also, I realized I was unclear about it
applying to safe and not unsafe code, and why. Nice
clarification. Thanks.
Joseph
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/16/15 4:24 PM, Steven Schveighoffer wrote: On 1/16/15 7:14 PM, Andrei Alexandrescu wrote: The DIP applies to @safe code only for now. Steve, could you please add a clarifying section. Thanks! -- Andrei OK, done. Please review. Just what the doctor prescribed, thanks! -- Andrei
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/16/15 6:01 PM, Andrei Alexandrescu wrote: On 1/16/15 2:52 PM, Daniel Kozak wrote: Why DIP says: Last Modified: 2015-01-11 but from history I see lots of changing after that date? I wish that were automated. Well, it does include last modified automatically at the bottom of the page. Is it worth keeping that manual entry? I tried to see if there was a way to reference that, but it's not possible from what I can tell. -Steve
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/16/15 4:56 PM, Steven Schveighoffer wrote: On 1/16/15 6:01 PM, Andrei Alexandrescu wrote: On 1/16/15 2:52 PM, Daniel Kozak wrote: Why DIP says: Last Modified: 2015-01-11 but from history I see lots of changing after that date? I wish that were automated. Well, it does include last modified automatically at the bottom of the page. Is it worth keeping that manual entry? I tried to see if there was a way to reference that, but it's not possible from what I can tell. Then I'd say just yank it. Apparently you can with an extension: http://www.mediawiki.org/wiki/Extension:LastModified Andrei
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/16/15 8:18 PM, Andrei Alexandrescu wrote:
On 1/16/15 4:56 PM, Steven Schveighoffer wrote:
On 1/16/15 6:01 PM, Andrei Alexandrescu wrote:
On 1/16/15 2:52 PM, Daniel Kozak wrote:
Why DIP says: Last Modified: 2015-01-11
but from history I see lots of changing after that date?
I wish that were automated.
Well, it does include last modified automatically at the bottom of the
page. Is it worth keeping that manual entry?
I tried to see if there was a way to reference that, but it's not
possible from what I can tell.
Then I'd say just yank it. Apparently you can with an extension:
http://www.mediawiki.org/wiki/Extension:LastModified
I figured it out, thanks in part to your link :)
{{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY}}
They HAVE to be capitalized (that took me a while to figure out).
I'll update the template. No sense in updating all the other proposals,
as they will then update to today :)
-Steve
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/16/15 5:51 PM, Steven Schveighoffer wrote:
On 1/16/15 8:18 PM, Andrei Alexandrescu wrote:
On 1/16/15 4:56 PM, Steven Schveighoffer wrote:
On 1/16/15 6:01 PM, Andrei Alexandrescu wrote:
On 1/16/15 2:52 PM, Daniel Kozak wrote:
Why DIP says: Last Modified: 2015-01-11
but from history I see lots of changing after that date?
I wish that were automated.
Well, it does include last modified automatically at the bottom of the
page. Is it worth keeping that manual entry?
I tried to see if there was a way to reference that, but it's not
possible from what I can tell.
Then I'd say just yank it. Apparently you can with an extension:
http://www.mediawiki.org/wiki/Extension:LastModified
I figured it out, thanks in part to your link :)
{{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY}}
They HAVE to be capitalized (that took me a while to figure out).
I'll update the template. No sense in updating all the other proposals,
as they will then update to today :)
Heh, nice insight :o). -- Andrei
Re: http://wiki.dlang.org/DIP25
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.
Re: http://wiki.dlang.org/DIP25
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
Re: http://wiki.dlang.org/DIP25
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;
Re: http://wiki.dlang.org/DIP25
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.
Re: http://wiki.dlang.org/DIP25
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.
Re: http://wiki.dlang.org/DIP25
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
Re: http://wiki.dlang.org/DIP25
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
Re: http://wiki.dlang.org/DIP25
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.
Re: http://wiki.dlang.org/DIP25
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.
Re: http://wiki.dlang.org/DIP25
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
Re: http://wiki.dlang.org/DIP25
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.
Re: http://wiki.dlang.org/DIP25
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 ?
Re: http://wiki.dlang.org/DIP25
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.
Re: http://wiki.dlang.org/DIP25
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 :)
Re: http://wiki.dlang.org/DIP25
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.
Re: http://wiki.dlang.org/DIP25
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
Re: http://wiki.dlang.org/DIP25
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.
Re: http://wiki.dlang.org/DIP25
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
Re: http://wiki.dlang.org/DIP25
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
Re: http://wiki.dlang.org/DIP25
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 ...
}
Re: http://wiki.dlang.org/DIP25
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?
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
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.
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
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.
Re: http://wiki.dlang.org/DIP25
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_detailpagev=P9FHlhWqbus#t=17
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
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.
Re: http://wiki.dlang.org/DIP25
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?
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
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.
Re: http://wiki.dlang.org/DIP25
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.
Re: http://wiki.dlang.org/DIP25
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...
Re: http://wiki.dlang.org/DIP25
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_detailpagev=P9FHlhWqbus#t=17 Umm, I don't understand?
Re: http://wiki.dlang.org/DIP25
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_detailpagev=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.
Re: http://wiki.dlang.org/DIP25
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.
Re: http://wiki.dlang.org/DIP25
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 intscope(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.
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
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
Re: http://wiki.dlang.org/DIP25
On 12/31/2014 3:23 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@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.
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
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.
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
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.
Re: http://wiki.dlang.org/DIP25
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.
Re: http://wiki.dlang.org/DIP25
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.
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
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.
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
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.
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
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.
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
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
Re: http://wiki.dlang.org/DIP25
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'!
Re: http://wiki.dlang.org/DIP25
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.
Re: http://wiki.dlang.org/DIP25
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. :)
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
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.
Re: http://wiki.dlang.org/DIP25
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).
Re: http://wiki.dlang.org/DIP25
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 :-)
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
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.
Re: http://wiki.dlang.org/DIP25
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.
Re: http://wiki.dlang.org/DIP25
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.
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
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
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
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
Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
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
