www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Blog post: What D got wrong

reply Atila Neves <atila.neves gmail.com> writes:
A few things that have annoyed me about writing D lately:

https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
Dec 11 2018
next sibling parent reply user1234 <user1234 1234.de> writes:
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
 A few things that have annoyed me about writing D lately:

 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
I agree about template lambdas. But is something that misses really an error ?
Dec 11 2018
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 11 December 2018 at 11:08:29 UTC, user1234 wrote:
 On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
 A few things that have annoyed me about writing D lately:

 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
I agree about template lambdas. But is something that misses really an error ?
It's debatable. I thought it was funny that it was an oversight given the fact that D had lambdas to avoid the problems that C++ used to have, then went and made the "same" mistake again.
Dec 11 2018
parent Mike Wey <mike-wey example.com> writes:
On 11-12-2018 12:10, Atila Neves wrote:
 On Tuesday, 11 December 2018 at 11:08:29 UTC, user1234 wrote:
 On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
 A few things that have annoyed me about writing D lately:

 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
I agree about template lambdas. But is something that misses really an error ?
It's debatable. I thought it was funny that it was an oversight given the fact that D had lambdas to avoid the problems that C++ used to have, then went and made the "same" mistake again.
It isn't as bad as the example in the blog post, this also works: ``` range.map!(fun).filter!(gun).join; ``` -- Mike Wey
Dec 11 2018
prev sibling next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
 A few things that have annoyed me about writing D lately:

 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
Really great article. I like the "UFCS for templates" idea. 12 years in and I still don't know what property is for!
 . The way to do eponymous templates right is to (obviously 
 renaming the feature) follow D’s own lead here and use either 
 this or This to refer to itself.
Brilliant.
Dec 11 2018
prev sibling next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
 A few things that have annoyed me about writing D lately:

 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
Nice! I like the eponymous templates idea, though it might get confusing with doubly nested eponymous templates and with mixin templates injecting constructors ( https://run.dlang.io/is/UYakit ) We really do need to figure out what to do with property
 Returning a reference
Wow, thats f*ck'n stupid! https://run.dlang.io/is/SAplYw
 Variables can’t be ref
not _quite true, foreach variables can be.
Dec 11 2018
next sibling parent Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 11 December 2018 at 12:51:56 UTC, Nicholas Wilson 
wrote:
 On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
 A few things that have annoyed me about writing D lately:

 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
Nice!
Thanks!
 I like the eponymous templates idea, though it might get 
 confusing with doubly nested eponymous templates
I'd say it would refer to the innermost template.
 and with mixin templates injecting constructors ( 
 https://run.dlang.io/is/UYakit )
I'd say it wouldn't work in mixin templates - is there such a thing as an eponymous mixin template now?
 We really do need to figure out what to do with  property

 Returning a reference
Wow, thats f*ck'n stupid! https://run.dlang.io/is/SAplYw
You're telling me - how do you think I found out? ;)
 Variables can’t be ref
not _quite true, foreach variables can be.
That's true and a weird edge case.
Dec 11 2018
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/11/2018 4:51 AM, Nicholas Wilson wrote:
 Returning a reference
Wow, thats f*ck'n stupid! https://run.dlang.io/is/SAplYw
It's quite deliberate. ref in C++ is a type constructor, but it's so special-cased to behave like a storage class, it might as well be one. In D it is. (For example, ref in C++ can only appear at the top level. There are no "pointers to refs".) refs exist so the lifetime of them can be controlled for memory safety. Treating them as flexibly as pointers would make that pretty difficult. refs are the primary way a memory safe container can expose pointers to its contents.
Dec 11 2018
parent reply Vijay Nayar <madric gmail.com> writes:
On Wednesday, 12 December 2018 at 07:44:12 UTC, Walter Bright 
wrote:
 On 12/11/2018 4:51 AM, Nicholas Wilson wrote:
 Returning a reference
Wow, thats f*ck'n stupid! https://run.dlang.io/is/SAplYw
It's quite deliberate. ref in C++ is a type constructor, but it's so special-cased to behave like a storage class, it might as well be one. In D it is. (For example, ref in C++ can only appear at the top level. There are no "pointers to refs".) refs exist so the lifetime of them can be controlled for memory safety. Treating them as flexibly as pointers would make that pretty difficult. refs are the primary way a memory safe container can expose pointers to its contents.
Could you please elaborate a little bit more on this? In the linked program, I had expected that "ref" would return a reference to "a" that would behave similar to a pointer. But when that reference is assigned to "b", and "b" is modified, "a" appears to retain its original value, implying that "b" is a copy. When was the copy of "a" made? Was it during the assignment to "b"? I use ref regularly, especially when I have to port C++ code that does exactly that, exposing modifiable references to its members. And in my experience it works quite well, especially for array types and classes. So what is the best way to understand this program and know why a copy of "a" is made?
Dec 19 2018
parent reply Neia Neutuladh <neia ikeran.org> writes:
On Wed, 19 Dec 2018 17:28:01 +0000, Vijay Nayar wrote:
 Could you please elaborate a little bit more on this?  In the linked
 program, I had expected that "ref" would return a reference to "a" that
 would behave similar to a pointer.
They work like pointers that automatically dereference when assigning to the base type. Only three things in D can be ref: * A function parameter * A function return value * A foreach variable (since that's either going to be a function return value, a function parameter, or a pointer, depending on what you're iterating over) So when the compiler sees something like: ref int foo(); auto a = foo(); It sees that the type of 'a' has to be the same as the return type of 'foo'. Except that's not possible, so it uses the nearest equivalent type: int. And if you have: ref int foo(); int a = foo(); That obviously converts by copying the value.
Dec 19 2018
next sibling parent reply Rubn <where is.this> writes:
On Wednesday, 19 December 2018 at 19:58:53 UTC, Neia Neutuladh 
wrote:
 On Wed, 19 Dec 2018 17:28:01 +0000, Vijay Nayar wrote:
 Could you please elaborate a little bit more on this?  In the 
 linked program, I had expected that "ref" would return a 
 reference to "a" that would behave similar to a pointer.
They work like pointers that automatically dereference when assigning to the base type. Only three things in D can be ref: * A function parameter * A function return value * A foreach variable (since that's either going to be a function return value, a function parameter, or a pointer, depending on what you're iterating over) So when the compiler sees something like: ref int foo(); auto a = foo(); It sees that the type of 'a' has to be the same as the return type of 'foo'. Except that's not possible, so it uses the nearest equivalent type: int. And if you have: ref int foo(); int a = foo(); That obviously converts by copying the value.
To be fair even in c++ this won't be a reference. int& foo(); auto a = foo(); // a == int auto& a = foo(); // a == int& So it shouldn't be that surprising.
Dec 19 2018
parent Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 19 December 2018 at 23:10:34 UTC, Rubn wrote:
 On Wednesday, 19 December 2018 at 19:58:53 UTC, Neia Neutuladh 
 wrote:
 [...]
To be fair even in c++ this won't be a reference. int& foo(); auto a = foo(); // a == int auto& a = foo(); // a == int& So it shouldn't be that surprising.
decltype(auto) a = foo(); // a == int& And you can explicitly declare `auto&` in C++, which you can't do in D.
Dec 20 2018
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 12/19/18 2:58 PM, Neia Neutuladh wrote:
 On Wed, 19 Dec 2018 17:28:01 +0000, Vijay Nayar wrote:
 Could you please elaborate a little bit more on this?  In the linked
 program, I had expected that "ref" would return a reference to "a" that
 would behave similar to a pointer.
They work like pointers that automatically dereference when assigning to the base type. Only three things in D can be ref: * A function parameter * A function return value * A foreach variable (since that's either going to be a function return value, a function parameter, or a pointer, depending on what you're iterating over) So when the compiler sees something like: ref int foo(); auto a = foo(); It sees that the type of 'a' has to be the same as the return type of 'foo'. Except that's not possible, so it uses the nearest equivalent type: int.
I would say it a little bit differently -- the return *type* of foo is int. In D, ref is not part of the type at all. For example, even when it *could* use ref, it doesn't: int x; ref int foo() { return x; } void bar(Args...)(Args args) { pragma(msg, __traits(isRef, args[0])); } bar(foo()); // outputs false at compile time The storage class is completely separate from the type. Which is different from C++, where it's like a storage class but is really a type constructor, hence Walter's post. -Steve
Dec 20 2018
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
 A few things that have annoyed me about writing D lately:

 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
If property worked for a thing to return a delegate, it would be useful. But noooo, we got worked up over syntax and forgot about semantics :(
Dec 11 2018
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 11 December 2018 at 12:52:20 UTC, Adam D. Ruppe wrote:
 On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
 A few things that have annoyed me about writing D lately:

 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
If property worked for a thing to return a delegate, it would be useful. But noooo, we got worked up over syntax and forgot about semantics :(
property is useful for setters. Now, IMHO setters are a code stink anyway but sometimes they're the way to go. I have no idea what it's supposed to do for getters (nor am I interested in learning or retaining that information) and never slap the attribute on.
Dec 11 2018
next sibling parent reply 0xEAB <desisma heidel.beer> writes:
On Tuesday, 11 December 2018 at 12:57:03 UTC, Atila Neves wrote:
 On Tuesday, 11 December 2018 at 12:52:20 UTC, Adam D. Ruppe 
 wrote:
 On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves 
 wrote:
 A few things that have annoyed me about writing D lately:

 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
If property worked for a thing to return a delegate, it would be useful. But noooo, we got worked up over syntax and forgot about semantics :(
property is useful for setters. Now, IMHO setters are a code stink anyway but sometimes they're the way to go. I have no idea what it's supposed to do for getters (nor am I interested in learning or retaining that information) and never slap the attribute on.
Well, one can use it for optics :) property { int x() { return this._x; } void x(int value) { this._x = value; } }
Dec 11 2018
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 11 December 2018 at 13:08:18 UTC, 0xEAB wrote:
 Well, one can use it for optics :)


  property
 {
     int x()
     {
         return this._x;
     }

     void x(int value)
     {
         this._x = value;
     }
 }
One could say getters and particularly setters don't really deserve a nicer way to write them. It's a code stink, it deserve a long ugly name. (10 years ago I would be in the other camp)
Dec 11 2018
parent reply dayllenger <dayllenger protonmail.com> writes:
On Tuesday, 11 December 2018 at 13:42:03 UTC, Guillaume Piolat 
wrote:
 One could say getters and particularly setters don't really 
 deserve a nicer way to write them. It's a code stink, it 
 deserve a long ugly name.  (10 years ago I would be in the 
 other camp)
Can you please explain it in more detail? I never read such about getters and setters.
Dec 11 2018
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 11 December 2018 at 14:00:10 UTC, dayllenger wrote:
 On Tuesday, 11 December 2018 at 13:42:03 UTC, Guillaume Piolat 
 wrote:
 One could say getters and particularly setters don't really 
 deserve a nicer way to write them. It's a code stink, it 
 deserve a long ugly name.  (10 years ago I would be in the 
 other camp)
Can you please explain it in more detail? I never read such about getters and setters.
Tell, don't ask: https://martinfowler.com/bliki/TellDontAsk.html Getters and setters break encapsulation - the client knows way too much about your struct/class. Whatever you were going to do with the data you got from the object, move it into a member function of that object's type. Setters are like that as well, but worse since mutable state is the root of all evil. Personally, I cringe whenever I have to use `auto` instead of `const` for a variable declaration.
Dec 12 2018
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 12 December 2018 at 14:48:23 UTC, Atila Neves wrote:
 On Tuesday, 11 December 2018 at 14:00:10 UTC, dayllenger wrote:
 On Tuesday, 11 December 2018 at 13:42:03 UTC, Guillaume Piolat 
 wrote:
 One could say getters and particularly setters don't really 
 deserve a nicer way to write them. It's a code stink, it 
 deserve a long ugly name.  (10 years ago I would be in the 
 other camp)
Can you please explain it in more detail? I never read such about getters and setters.
Tell, don't ask: https://martinfowler.com/bliki/TellDontAsk.html
Sometimes formulated slightly differently as "Law of Demeter" https://en.wikipedia.org/wiki/Law_of_Demeter if you like more pompous names.
Dec 12 2018
parent JN <666total wp.pl> writes:
On Wednesday, 12 December 2018 at 20:12:54 UTC, Guillaume Piolat 
wrote:
 On Wednesday, 12 December 2018 at 14:48:23 UTC, Atila Neves 
 wrote:
 On Tuesday, 11 December 2018 at 14:00:10 UTC, dayllenger wrote:
 On Tuesday, 11 December 2018 at 13:42:03 UTC, Guillaume 
 Piolat wrote:
 One could say getters and particularly setters don't really 
 deserve a nicer way to write them. It's a code stink, it 
 deserve a long ugly name.  (10 years ago I would be in the 
 other camp)
Can you please explain it in more detail? I never read such about getters and setters.
Tell, don't ask: https://martinfowler.com/bliki/TellDontAsk.html
Sometimes formulated slightly differently as "Law of Demeter" https://en.wikipedia.org/wiki/Law_of_Demeter if you like more pompous names.
Law of Demeter is different. Law of Demeter basically translates to "don't have more than one dot", like x.y() is fine, x.y.z() isn't because it makes too many assumptions about internals of x and y. Properties have use when the setting or getting the variable isn't a trivial assignment. For example, sometimes the units need to be converted along the way. In many cases, especially when GUI programming, you might want to do additional actions when settings/getting a variable, like calling listeners to notify them of the value change so that they can change the value in the GUI widget automatically.
Dec 12 2018
prev sibling next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 11 December 2018 at 12:57:03 UTC, Atila Neves wrote:
 On Tuesday, 11 December 2018 at 12:52:20 UTC, Adam D. Ruppe 
 wrote:
 On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves 
 wrote:
 A few things that have annoyed me about writing D lately:

 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
If property worked for a thing to return a delegate, it would be useful. But noooo, we got worked up over syntax and forgot about semantics :(
property is useful for setters. Now, IMHO setters are a code stink anyway but sometimes they're the way to go. I have no idea what it's supposed to do for getters (nor am I interested in learning or retaining that information) and never slap the attribute on.
My view of getters is that they serve as a contract of between contractor and client stating "You can't modify this value, I however can".
Dec 11 2018
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Dec 11, 2018 at 12:57:03PM +0000, Atila Neves via
Digitalmars-d-announce wrote:
 On Tuesday, 11 December 2018 at 12:52:20 UTC, Adam D. Ruppe wrote:
 On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
 A few things that have annoyed me about writing D lately:
 
 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
If property worked for a thing to return a delegate, it would be useful. But noooo, we got worked up over syntax and forgot about semantics :(
property is useful for setters. Now, IMHO setters are a code stink anyway but sometimes they're the way to go. I have no idea what it's supposed to do for getters (nor am I interested in learning or retaining that information) and never slap the attribute on.
You don't need property for setters. This works: struct S { void func(int x); } S s; s.func = 1; Of course, it's generally not a good idea to call it `func` when the intent is to emulate a member variable. :-D I agree setters are a code stink, but only when they are trivial: struct S { private int _x; // This is a code smell: just make _x public, dammit! void x(int val) { _x = val; } } But they can be very useful for non-trivial use cases. Recently I wrote code that auto-generates a nice D API for setting GLSL inputs. So instead of writing: FVec position; glUniform3fv(myshader.u_dirLightId_pos, 1, position[].ptr); I write: FVec position; myshader.position = position; // much more readable and less error prone! with myshader.position defined as a setter function that does that ugly glUniform3fv call for me. Plus, I can hide away that ugly internal detail of attribute position IDs and make it private, instead of exposing it to the world and adding a needless GL dependency to client code. (E.g., now I have the possibility of substituing a Direct3D backend for the OpenGL just by emitting a different implementation for myshader.position. The calling code doesn't need to be touched.) T -- If you think you are too small to make a difference, try sleeping in a closed room with a mosquito. -- Jan van Steenbergen
Dec 11 2018
prev sibling parent reply Kagamin <spam here.lot> writes:
On Tuesday, 11 December 2018 at 12:57:03 UTC, Atila Neves wrote:
  property is useful for setters. Now, IMHO setters are a code 
 stink anyway but sometimes they're the way to go. I have no 
 idea what it's supposed to do for getters (nor am I interested 
 in learning or retaining that information) and never slap the 
 attribute on.
Imagine you have void delegate() prop() and use the property without parentheses everywhere then suddenly m.prop() doesn't call the delegate. So it's mostly for getters and should be used only in edge cases, most code should be fine with optional parens.
inout
Template this can accomplish the same thing and is more useful 
anyway.
"Everything is a template" is a spiritual successor to "everything is an object" hype :)
Returning a reference
It’s practically pointless.
See https://github.com/dlang/druntime/blob/master/src/core/stdc/errno.d#L66 Also AFAIK alias this doesn't dereference pointers automatically, and retaining the pointer may be not desirable.
I think there’s a general consensus that  safe, pure and 
immutable should be default.
I can agree there are at least 5 people holding that firm belief, but that's hardly a consensus.
I’ve lost count now of how many times I’ve had to write  safe 
 nogc pure nothrow const scope return. Really.
If immutable was default, wouldn't you still need to write const attribute everywhere, and nogc, and nothrow? Strings are like the only relevant immutable data structure (and they are already immutable), everything else is inherently mutable except for use cases with genuine need for immutability like a shared cache of objects.
Dec 12 2018
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, December 12, 2018 6:03:39 AM MST Kagamin via Digitalmars-d-
announce wrote:
 On Tuesday, 11 December 2018 at 12:57:03 UTC, Atila Neves wrote:
  property is useful for setters. Now, IMHO setters are a code
 stink anyway but sometimes they're the way to go. I have no
 idea what it's supposed to do for getters (nor am I interested
 in learning or retaining that information) and never slap the
 attribute on.
Imagine you have void delegate() prop() and use the property without parentheses everywhere then suddenly m.prop() doesn't call the delegate. So it's mostly for getters and should be used only in edge cases, most code should be fine with optional parens.
Except that property does not currently have any effect on this. The delegate case (or really, the case of callables in general) is one argument for keeping property for using in that particular corner case, since without it, having property functions that return callables simply doesn't work, but property has never been made to actually handle that case, so having property functions that return callables has never worked in D. It's certainly been discussed before, but the implementation has never been changed to make it work. If/when we finally rework property, that use case would be the number one reason to not simply get rid of property, but until then, it doesn't actually fix that use case. As things stand, property basically just serves as documentation of intent for the API and as a way to screw up type introspection by having the compiler lie about the type of the property.
I think there’s a general consensus that  safe, pure and
immutable should be default.
I can agree there are at least 5 people holding that firm belief, but that's hardly a consensus.
There are definitely people who want one or more of those attributes as the default, but I very much doubt that it's a consensus. It wouldn't surprise me if safe or pure by default went over fairly well, but I'm sure that immutable or const by default would be far more controversial, because that's a big shift from what C-derived languages normally do. Personally, I would be very unhappy if it were the default, though I know that there are some folks who would very much like to see const or immutable be the default.
I’ve lost count now of how many times I’ve had to write  safe
 nogc pure nothrow const scope return. Really.
If immutable was default, wouldn't you still need to write const attribute everywhere, and nogc, and nothrow? Strings are like the only relevant immutable data structure (and they are already immutable), everything else is inherently mutable except for use cases with genuine need for immutability like a shared cache of objects.
If immutable were the default, then I expect that writing types that worked with immutable would become more common, because it would then be encouraged by the language, but I think that your average type is written to work as mutable (and maybe const), and it's a pretty big shift to write types to be immutable unless you're talking about simple POD types, so if immutable became the default, I expect that mutable (or whatever the modifier to make a type mutable would be) would start getting plastered everywhere. And without the range API being changed, ranges wouldn't work unless you marked them as mutable, making const or immutable by default a bit of a mess for what would now be idiomatic D code (though if the default were changed to const or immutable, we'd probably see the range API be changed to use the classic, functional head/tail list mechanism rather than front and popFront, which could very well be an improvement anyway). - Jonathan M Davis
Dec 12 2018
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Dec 12, 2018 at 02:10:31PM -0700, Jonathan M Davis via
Digitalmars-d-announce wrote:
 On Wednesday, December 12, 2018 6:03:39 AM MST Kagamin via Digitalmars-d-
 announce wrote:
[...]
 Imagine you have void delegate() prop() and use the property
 without parentheses everywhere then suddenly m.prop() doesn't
 call the delegate. So it's mostly for getters and should be used
 only in edge cases, most code should be fine with optional parens.
Except that property does not currently have any effect on this. The delegate case (or really, the case of callables in general) is one argument for keeping property for using in that particular corner case, since without it, having property functions that return callables simply doesn't work, but property has never been made to actually handle that case, so having property functions that return callables has never worked in D. It's certainly been discussed before, but the implementation has never been changed to make it work.
Yep. Basically, property as currently implemented is useless, and I've stopped bothering with it except where Phobos requires it.
 If/when we finally rework  property, that use case would be the number
 one reason to not simply get rid of  property, but until then, it
 doesn't actually fix that use case. As things stand,  property
 basically just serves as documentation of intent for the API and as a
 way to screw up type introspection by having the compiler lie about
 the type of the property.
[...] Haha yeah, currently property confers no real benefits and only comes with bad (and probably unexpected) side-effects. More confirmation that it's a waste of time and not worth my attention. If the delegate property thing is the only real use case for property, it seems quite out-of-proportion that an entire -identifier in the language is dedicated just for this purpose. One would've thought D ought to be better designed than this... T -- Gone Chopin. Bach in a minuet.
Dec 12 2018
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
 A few things that have annoyed me about writing D lately:

 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
One thing that could be improved in this post is separating things that can't reasonably be either fixed or added as enhancements vs. things that would be big breaking changes. I would think UFCS chain for templates, template lambdas, and eponymous template changes are all things that could be added or changed without breaking any code, whereas safe by default would break a bunch of code. I'm not sold on immutable by default yet, but I think all the attributes should be able to be used with the block and colon syntax.
Dec 11 2018
prev sibling next sibling parent Daniel Kozak <kozzi11 gmail.com> writes:
On Tue, Dec 11, 2018 at 11:50 AM Atila Neves via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 A few things that have annoyed me about writing D lately:

 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
Eponymous templates - workaround https://run.dlang.io/is/qIvcVH
Dec 11 2018
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 12/11/18 5:45 AM, Atila Neves wrote:
 A few things that have annoyed me about writing D lately:
 
 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
Agree with most of this. UFCS for templates would be awesome, but the syntax is trickier, since instantiation uses ! instead of . I can't see how you get around the ambiguities, especially when a template could be a UFCS function. inout: template This doesn't work the same (no guarantee it doesn't mutate the data). And it still generates multiple copies of the same function. As I said in my dconf 2016 presentation and in numerous debates on this forums, the only reason to care about const or inout is if you care about mutability guarantees on the callee. We can make do with templates and immutable without either of those features. property: This was almost about to be awesome, but squabbling amongst the D core team killed it. Now, it's only a very obscure difference: struct S { int _x; int x1() { return _x; } property int x2() { return _x; } } pragma(msg, typeof(S.x1)); // int() pragma(msg, typeof(S.x2)); // int Which is COMPLETELY USELESS, since you have to handle both cases anyway. -Steve
Dec 11 2018
next sibling parent reply Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Tuesday, 11 December 2018 at 14:38:25 UTC, Steven 
Schveighoffer wrote:
 On 12/11/18 5:45 AM, Atila Neves wrote:
 A few things that have annoyed me about writing D lately:
 
 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
Agree with most of this. UFCS for templates would be awesome, but the syntax is trickier, since instantiation uses ! instead of . I can't see how you get around the ambiguities, especially when a template could be a UFCS function.
I believe a reasonable case can be made for .! for UFCS - it's currently invalid syntax and will not compile, and ! is the symbol we already associate with template instantiation: alias memberFunctions = __traits(allMembers, T) .!staticMap!Member .!Filter!(isSomeFunction); -- Simen
Dec 11 2018
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Dec 11, 2018 at 03:34:28PM +0000, Simen Kjærås via
Digitalmars-d-announce wrote:
[...]
 I believe a reasonable case can be made for .! for UFCS - it's
 currently invalid syntax and will not compile, and ! is the symbol we
 already associate with template instantiation:
 
 alias memberFunctions = __traits(allMembers, T)
     .!staticMap!Member
     .!Filter!(isSomeFunction);
[...] +1. T -- Too many people have open minds but closed eyes.
Dec 11 2018
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 11 December 2018 at 15:34:28 UTC, Simen Kjærås wrote:
 I believe a reasonable case can be made for .! for UFCS - it's 
 currently invalid syntax and will not compile, and ! is the 
 symbol we already associate with template instantiation:

 alias memberFunctions = __traits(allMembers, T)
     .!staticMap!Member
     .!Filter!(isSomeFunction);

 --
   Simen
Perhaps. I also think that it might be good if types could be results of compile-ime expressions, including ufcs expressions (so that 42.typeof would become legal, meaning an int).
Dec 11 2018
parent Meta <jared771 gmail.com> writes:
On Tuesday, 11 December 2018 at 20:44:28 UTC, Dukc wrote:
 On Tuesday, 11 December 2018 at 15:34:28 UTC, Simen Kjærås 
 wrote:
 I believe a reasonable case can be made for .! for UFCS - it's 
 currently invalid syntax and will not compile, and ! is the 
 symbol we already associate with template instantiation:

 alias memberFunctions = __traits(allMembers, T)
     .!staticMap!Member
     .!Filter!(isSomeFunction);

 --
   Simen
Perhaps. I also think that it might be good if types could be results of compile-ime expressions, including ufcs expressions (so that 42.typeof would become legal, meaning an int).
I vaguely remember a very ancient version of D that had <expression>.typeof instead of typeof(<expression>). This might've been D1... the details are fuzzy.
Dec 11 2018
prev sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
On Tuesday, 11 December 2018 at 14:38:25 UTC, Steven 
Schveighoffer wrote:

  property: This was almost about to be awesome, but squabbling 
 amongst the D core team killed it.
Yes, the problem with property is that it is neither correctly implemented nor completely implemented. And to do the former something will have to break. Note that you can't use binary assignment operators on parentheses-less function calls, and returning by ref is not a solution either. Not only does that break encapsulation, but some property functions may not return an addressable lvalue (e.g. when working with bitfields). One might be able to fix the property implementation, but now, there's so much disdain for the incorrect, incomplete property implementation it's going to take some serious sweetener to remove the bitter taste from some people's mouths. Mike
Dec 11 2018
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Dec 11, 2018 at 10:45:39AM +0000, Atila Neves via
Digitalmars-d-announce wrote:
 A few things that have annoyed me about writing D lately:
 
 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
About UFCS chains for templates: totally agree! I found myself wishing for exactly that, many times. I'd even venture to say we should cook up a DIP for it. To prevent confusion and potential ambiguity with non-template UFCS chains, I propose using a separate operator, perhaps `.!`: alias blah = AliasSeq!(...) .!firstTemplate!(...) .!secondTemplate!(...) ...; Template lambdas have also been an annoyance for me. But again, there's a need to distinguish between a template lambda and a non-template lambda. And yes, I've also run into the eponymous template renaming problem. But I think it will be a pretty small and safe change to use `this` instead of repeating the template name? And while we're at it, might as well use `this` for recursive templates too. So we'd have something like: template Eponymous(T...) { static if (T.length == 0) enum this = 1; else enum this = 1 + 2*this!(T[1 .. $]); } Now we can freely rename Eponymous without also having to rename the occurrences of `this`, which in current syntax would also have to be spelt out as `Eponymous`. Though we probably have to write it as `This` instead, in order to prevent ambiguity when working with class templates. property getters... I've pretty much given up on property by this point, except for the few places (primarily isInputRange and its ilk) where property is explicitly tested for. Optional parens and the equivalence of `func(1)` vs. `func = 1` have made the distinction between property and non- property more-or-less irrelevant except for language lawyers and corner cases that nobody uses. Dmd's -property flag is a flop that nobody uses anymore. There have been a few efforts in the past for reviving property, but nothing has come of it, and in the recent years nobody has even bothered to talk about it anymore. So, tl;dr: property is moribund, if not completely dead. As far as I'm concerned, it belongs only in the history books of D now. inout... it's still useful for reducing template bloat in certain cases. But yeah, it has some not-very-pretty corner cases that I don't really want to talk about right now. But for the most part, the niche cases for which it's intended still work pretty well. It can be a life-saver when you try to be (slightly) const-correct in your code. Of course, const is a giant bear to work with -- it's an all-or-nothing deal that can require refactoring your *entire* codebase -- and generally I don't bother with it except for leaf modules that don't affect too much else. Trying to be const-correct in your core application logic can quickly turn into a nightmare -- and inout is also implicated in such cases. And yeah, ref as a storage class rather than part of the type is a strange concept that seems incongruous with much of the rest of the language. Its asymmetry with type qualifiers makes it hard to reason about (you have to shift mental gears when parsing it, which hampers easy understanding of code). I generally avoid it except in quick-hack cases, e.g., to make opIndex work with assignment without actually writing a separate opIndexAssign, or to grant by-reference semantics to struct parameters (but in the latter case I've often found it better to just change the struct to a class instead). So it's a *necessary* part of the language, but it feels a lot like a square peg jammed in a round hole sometimes. If I were to redesign ref, I'd do it a lot differently. As for attribute soup... I've mostly given up on writing attributes. I just stick () in front of every function parameter list to turn them into templates, and let the compiler do auto-inference for me. The only time I'd spell out attributes is in unittests, or in the rare case where I want to ensure a certain attribute is in effect. But seriously, in the grand scheme of things, attributes are an added annoyance that nobody wants to deal with (and do so only grudgingly when it cannot be helped). Attributes need to be auto-inferred everywhere. Nothing else is scalable. Of course, I realize that it's a bit too late to have auto inference in non-template functions, but I fully applaud Walter's move to apply inference to auto functions. The wider the scope of auto inference, the less attribute soup needs to be visible in your code, and the better it will be. In an ideal world, attributes would be completely invisible, and completely inferred and propagated by the compiler via static analysis. (Yes I know this doesn't work with separate compilation. But in theory, it *should*. The compiler should just store attributes in a special section in the object file and load them upon import. The user shouldn't even see them except when you need to specify them explicitly for clarity or for enforcement.) T -- Never trust an operating system you don't have source for! -- Martin Schulze
Dec 11 2018
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Dec 11, 2018 at 03:03:19PM +0100, Daniel Kozak via
Digitalmars-d-announce wrote:
    On Tue, Dec 11, 2018 at 11:50 AM Atila Neves via Digitalmars-d-announce
    <[1]digitalmars-d-announce puremagic.com> wrote:
 
      A few things that have annoyed me about writing D lately:
 
      [2]https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
 
    Eponymous templates - workaround
    [3]https://run.dlang.io/is/qIvcVH
[...] Clever! Perhaps this should be proposed as the lowering in a DIP for eponymous templates improvement. T -- Тише едешь, дальше будешь.
Dec 11 2018
prev sibling next sibling parent Meta <jared771 gmail.com> writes:
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
 A few things that have annoyed me about writing D lately:

 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
Template lambdas and better eponymous template syntax are the two big ones that I would really like. It's very painful not having them in code that makes heavy use of metaprogramming.
Dec 11 2018
prev sibling next sibling parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
 A few things that have annoyed me about writing D lately:

 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
 No UFCS chain for templates.
 No template lambdas.
You can write code like this today via library that I wrote ;) ``` import std.conv : to; auto filterMembers(alias pred, type)(type _) { import std.format : format; alias MemberType(T, string name) = typeof(__traits(getMember, T, name)); return l!(__traits(allMembers, type.get)) .staticMap!(name => π!(MemberType!(type.get, name.get), name.get)) .staticFilter!pred .staticMap!(t => "%s %s".format(t.get[0].stringof, t.get[1])); } enum members = [ π!S.filterMembers!(t => is(t.get[0] : U[], U)).get ]; pragma (msg, members.to!string); // Prints: ["string wxyz", "int[4] uvwxyz"] struct S { int x; double xy; int xyz; string wxyz; S* vwxyz; int[4] uvwxyz; } ``` Here's a full example: [2] Though, I agree that this certainly not as elegant and straightforward to use as what a language feature could provide. [1]: https://github.com/dlang/phobos/pull/5977/files#diff-33b50b4967214bfd07ca2ebb7bbc023cR1218 [2]: https://run.dlang.io/gist/ZombineDev/a808c94857de84858accfb094c19bf77?compiler=dmd&args=-unittest%20-main
Dec 11 2018
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, December 12, 2018 3:49:51 PM MST H. S. Teoh via Digitalmars-d-
announce wrote:
 If the delegate property thing is the only real use case for  property,
 it seems quite out-of-proportion that an entire  -identifier in the
 language is dedicated just for this purpose. One would've thought D
 ought to be better designed than this...
Originally, the idea was to restrict property syntax to functions marked with property, which would mean no more lax parens. If it's a property function, then it must be called like one, and if it's not, then it must be called as a function (i.e. with parens), whereas right now, we have this mess where folks can use parens or not however they feel like. That doesn't work well with being able to swap between property functions and public variables, and it makes generic code harder, because in general, you can't rely on whether something is called with parens or not, meaning that the symbol in question has to be an actual function (where parens are optional) instead of being allowed to be a different kind of callable (which requires parens) or be a variable (which can't have parens). property would have fixed all of that by forcing functions to either be called with or without parens based on what they're used for, allowing generic code to rely on more than convention ensuring that symbols are called consistently with or without parens (and thus allow symbols other than functions to be reliably used in place of functions where appropriate). So, as originally envisioned, property was anything but useless. However, all of that became extremely unpopular once UFCS became a thing, because most folks didn't like having an empty set of parens when calling a templated function that had a template argument that used parens, and as such, they wanted to be able to continue to drop the parens, which goes against the core idea behind property. So, the end result is that the original plans for property got dropped, and plenty of folks would be very unhappy if we went in that direction now - but it's still the case that property was supposed to solve a very real problem, and that problem remains unsolved. As things stand, you have to be _very_ careful when using anything other than a function in a generic context that normally uses a function, because there's no guarantee that using something other than a function will work due to the lack of guarantee of whether parens will be used or not. It tends to work better with variables than with callables, because dropping parens is so popular, and callables aren't, but it's still a problem. Anyone who wants to use a callable instead of a function in generic code is almost certainly in for a world of hurt unless they're in control of all of the code involved - and that's without even getting into the issue of property functions that return callables (those simply don't work at all). Template constraints combat this to an extent in that they end up requiring that the construct in question either be callable with parens or usable without them, but that places no restrictions on the code that actually uses the symbols, making it easy for code to use parens when it shouldn't or not use parens when it should and then run into problems when it's given a type that conforms to the template constraint, but the code didn't use the symbol in the same way as the constraint. The only thing things that really prevent this from be a much bigger problem than it is is that many folks do follow the conventions set forth by the template constraint (e.g. always calling front without parens) and the fact that in most cases, it's the lack of parens which is required, and using variables instead of functions is far more popular than using callables instead of functions. So, convention is really all that prevents this from being a bigger problem, and the end result is that callables in generic code are borderline useless. On example of trying to work around this problem is that not all that long ago, isInputRange was actually changed to use popFront without parens just so that folks could rely on being able to call it without parens, since previously it was possible to use a delegate or other callable for popFront instead of a function, which would then not have worked with any code where folks didn't bother to put parens on popFront when calling it. All in all though, I think that the fact that we aren't strict about parens usage mostly kills the use of callables in generic code except in cases where you're in control of all of the code involved. It could be argued that callables are desirable infrequently enough that being able to drop parens when calling functions for whatever syntactic beauty supposedly comes with outweighs the loss, but that doesn't mean that the problem isn't there, just that many folks don't care and think that the tradeoff is worth it. - Jonathan M Davis
Dec 12 2018
prev sibling next sibling parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
 A few things that have annoyed me about writing D lately:

 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
That was a really good blog post, however I am strongly against the following sentence: "I think there’s a general consensus that safe, pure and immutable should be default." It's not at all a general consensus and doing this would literally break all the existing D code. Without discussing all the technical aspects, this will severely impact the adoption rate of D because it will make it very complicated for people coming from a C/C++/Java background to accommodate with the language. In addition, this is completely against D's liberal philosophy where you can program however you want.
Dec 13 2018
next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 13 December 2018 at 09:40:45 UTC, RazvanN wrote:
 "I think there’s a general consensus that  safe, pure and 
 immutable should be default."

 It's not at all a general consensus and doing this would 
 literally break all the existing D code. Without discussing all 
 the technical aspects, this will severely impact the adoption 
 rate of D because it will make it very complicated for people 
 coming from a C/C++/Java background to accommodate with the 
 language. In addition, this is completely against D's liberal 
 philosophy where you can program however you want.
+1 The point of them not being default is that you can ignore them if you want, and create added-value instead of proving properties in your programs. So a D program can start its life being crap and get better _if_ it creates any value.
Dec 13 2018
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Thursday, 13 December 2018 at 09:40:45 UTC, RazvanN wrote:
 On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
 A few things that have annoyed me about writing D lately:

 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
That was a really good blog post, however I am strongly against the following sentence: "I think there’s a general consensus that safe, pure and immutable should be default." It's not at all a general consensus and doing this would literally break all the existing D code. Without discussing all the technical aspects, this will severely impact the adoption rate of D because it will make it very complicated for people coming from a C/C++/Java background to accommodate with the language. In addition, this is completely against D's liberal philosophy where you can program however you want.
My impression is that it's a consensus that it _should_, but it's not going to happen due to breaking existing code.
 this will severely impact the adoption rate of D because it 
 will make it very complicated for people coming from a 
 C/C++/Java background to accommodate with the language
How? Rust has immutable and safe by default and it's doing fine.
 this is completely against D's liberal philosophy where you can 
 program however you want.
It would be if the change weren't accompanied by adding `impure` and some sort of mutable auto. system already exists. It's a question of opting out (like with variable initialisation) instead of opting in.
Dec 13 2018
next sibling parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
On Thursday, 13 December 2018 at 10:14:45 UTC, Atila Neves wrote:
 On Thursday, 13 December 2018 at 09:40:45 UTC, RazvanN wrote:
 On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves 
 wrote:
 A few things that have annoyed me about writing D lately:

 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
That was a really good blog post, however I am strongly against the following sentence: "I think there’s a general consensus that safe, pure and immutable should be default." It's not at all a general consensus and doing this would literally break all the existing D code. Without discussing all the technical aspects, this will severely impact the adoption rate of D because it will make it very complicated for people coming from a C/C++/Java background to accommodate with the language. In addition, this is completely against D's liberal philosophy where you can program however you want.
My impression is that it's a consensus that it _should_, but it's not going to happen due to breaking existing code.
 this will severely impact the adoption rate of D because it 
 will make it very complicated for people coming from a 
 C/C++/Java background to accommodate with the language
How? Rust has immutable and safe by default and it's doing fine.
D and Rust are competing to get the C/C++/Java/Python market share. In order to do that they should make it simple for developers to convert to the new language. Due to its design, Rust is insanely hard to master, which on the long run I think will kill the language despite of the advantages it offers. On the other side, consider die hard C fans: they are willing to accept the possibility of a buffer overflow simply because they want more power. Do you honestly think that they will ever take D into account if safe and immutable data will be the default?
 this is completely against D's liberal philosophy where you 
 can program however you want.
It would be if the change weren't accompanied by adding `impure` and some sort of mutable auto. system already exists. It's a question of opting out (like with variable initialisation) instead of opting in.
It still is, because the user is imposed to work in certain conditions that some might not want to.
Dec 13 2018
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Dec 13, 2018 at 10:29:10AM +0000, RazvanN via Digitalmars-d-announce
wrote:
[...]
 D and Rust are competing to get the C/C++/Java/Python market share. In
 order to do that they should make it simple for developers to convert
 to the new language. Due to its design, Rust is insanely hard to
 master, which on the long run I think will kill the language despite
 of the advantages it offers.  On the other side, consider die hard C
 fans: they are willing to accept the possibility of a buffer overflow
 simply because they want more power. Do you honestly think that they
 will ever take D into account if  safe and immutable data will be the
 default?
Why not? You can opt out. It's not as though you're forced to use immutable everything and nothing but, like in a pure functional language. Just tack on system or mutable when you need to. Some people balk at the idea of `mutable` being sprinkled everywhere in their code, but that's really just a minor syntactic issue. There's already precedent for using `val` and `var` -- it couldn't get easier to type than that. The syntax is not a real problem. [...]
 It would be if the change weren't accompanied by adding `impure` and
 some sort of mutable auto.  system already exists. It's a question
 of opting out (like with variable initialisation) instead of opting
 in.
It still is, because the user is imposed to work in certain conditions that some might not want to.
No, there's always the option of opting out. There's no imposition. It's not like Java where everything must be a class, no matter what. You can write system code or mutable variables to your heart's content. The idea is to *default* to safe so that when the programmer doesn't really care either way, the default behaviour gives you memory safety. Or default to immutable, so that unless the programmer consciously wants to mutate state, he'll get the benefit of being warned about any unintended mutation. Plus optimization benefits for variables that don't need to be mutable. But defaults are called defaults because they're there to be overridden. T -- LINUX = Lousy Interface for Nefarious Unix Xenophobes.
Dec 13 2018
parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 13 December 2018 at 17:07:58 UTC, H. S. Teoh wrote:
 [snip]

 Why not?  You can opt out. It's not as though you're forced to 
 use immutable everything and nothing but, like in a pure 
 functional language.  Just tack on  system or mutable when you 
 need to.
Mutable might be a little easier since it applies only to variables and member functions. If safe is the default, including for main, then any system block in your program and you also have to make main trusted or system too.
Dec 13 2018
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 13 December 2018 at 10:29:10 UTC, RazvanN wrote:
 Do you honestly think that they will ever take D into account 
 if  safe and immutable data will be the default?
D needs to stop chasing after what you think people think they want and just start being good for us. The majority of my code is written pretty permissively - I like my pointers, my gotos, my GC, my exceptions. But I'm willing to consider the change because I actually don't think it will be that big of a hassle, and will be better overall. I wanna show you something: /// Static convenience functions for common color names nothrow pure nogc safe static Color transparent() { return Color(0, 0, 0, 0); } The attribute spam is almost longer than the function itself. And I don't even personally care - I only put those in because some library user who did care filed a bug report, and that was before I would answer those with "WON'T FIX. D's attributes are a misdesigned waste of time. You shouldn't bother with them either" If the defaults were swapped though, that would just work. Both for me and for my library users. And that is worth looking at. Though, I think we could also get a lot of mileage out of fixing two glaring problems with the status quo: 1) making attr: at the top descend into aggregates consistently and 2) LETTING US TURN THEM OFF. SERIOUSLY WHY DON'T WE HAVE `virtual`, `throws`, `impure` AND THE REST?! THIS IS SO OBVIOUS AND THE LACK OF THEM IS UNBELIEVABLY FRUSTRATING.
Dec 13 2018
next sibling parent dayllenger <dayllenger protonmail.com> writes:
On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe 
wrote:
 I wanna show you something:

 /// Static convenience functions for common color names
 nothrow pure  nogc  safe
 static Color transparent() { return Color(0, 0, 0, 0); }
Enums could resolve this particular case. My thought on this situation is to implement tuple expansion in attributes just like in function parameters, and complete DIP1012. Then we can write so: --- alias noble = AliasSeq!(pure, nothrow, nogc, safe); int queryStuff() const noble { ... } ---
Dec 13 2018
prev sibling next sibling parent Neia Neutuladh <neia ikeran.org> writes:
On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe 
wrote:
 Though, I think we could also get a lot of mileage out of 
 fixing two glaring problems with the status quo: 1) making 
 attr: at the top descend into aggregates consistently and 2) 
 LETTING US TURN THEM OFF. SERIOUSLY WHY DON'T WE HAVE 
 `virtual`, `throws`, `impure` AND THE REST?! THIS IS SO OBVIOUS 
 AND THE LACK OF THEM IS UNBELIEVABLY FRUSTRATING.
While I might quibble about nothrow being the default, I wouldn't care once attributes descend into aggregates. https://issues.dlang.org/show_bug.cgi?id=7616
Dec 13 2018
prev sibling next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe 
wrote:

 2) LETTING US TURN THEM OFF. SERIOUSLY WHY DON'T WE HAVE 
 `virtual`, `throws`, `impure` AND THE REST?! THIS IS SO OBVIOUS 
 AND THE LACK OF THEM IS UNBELIEVABLY FRUSTRATING.
Well, we had virtual, it was reverted.... I know, I'm repeating this kind of things in a trollish way since 2004, but... *sigh* /Paolo
Dec 13 2018
prev sibling next sibling parent reply Pjotr Prins <pjotr.public12 thebird.nl> writes:
On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe 
wrote:
 On Thursday, 13 December 2018 at 10:29:10 UTC, RazvanN wrote:
 Do you honestly think that they will ever take D into account 
 if  safe and immutable data will be the default?
D needs to stop chasing after what you think people think they want and just start being good for us. The majority of my code is written pretty permissively - I like my pointers, my gotos, my GC, my exceptions. But I'm willing to consider the change because I actually don't think it will be that big of a hassle, and will be better overall. I wanna show you something: /// Static convenience functions for common color names nothrow pure nogc safe static Color transparent() { return Color(0, 0, 0, 0); } The attribute spam is almost longer than the function itself.
Isn't it the way forward that the compiler deduces these attributes and fills them in automatically? All these can be inferenced. Only when the caller wants to guarantee, say pure, it could add it explicitly. I read somewhere that the compiler already does this to some degree. And even the generated docs should be able to show it.
Dec 18 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, December 18, 2018 3:36:15 AM MST Pjotr Prins via Digitalmars-d-
announce wrote:
 On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe

 wrote:
 On Thursday, 13 December 2018 at 10:29:10 UTC, RazvanN wrote:
 Do you honestly think that they will ever take D into account
 if  safe and immutable data will be the default?
D needs to stop chasing after what you think people think they want and just start being good for us. The majority of my code is written pretty permissively - I like my pointers, my gotos, my GC, my exceptions. But I'm willing to consider the change because I actually don't think it will be that big of a hassle, and will be better overall. I wanna show you something: /// Static convenience functions for common color names nothrow pure nogc safe static Color transparent() { return Color(0, 0, 0, 0); } The attribute spam is almost longer than the function itself.
Isn't it the way forward that the compiler deduces these attributes and fills them in automatically? All these can be inferenced. Only when the caller wants to guarantee, say pure, it could add it explicitly. I read somewhere that the compiler already does this to some degree. And even the generated docs should be able to show it.
In general, functions that have to have their source available have their attributes inferred. So, templated functions, lambdas, and auto return functions all have attribute inference at this point. Attribute inference was introduced originally as being only for templated functions, because you _have_ to have it for them for them to really work with attributes (at least in any situation where whether an attribute is applicable depends on the template arguments - which is frequently the case), but it's been expanded over time. However, D's compilation model is such that many functions will never have attribute inference, because it's frequently not guaranteed that the compiler has the source code for a function in all cases where it's called. That being said, there are some serious downsides to attribute inference. It makes it much harder to know which attributes actually apply to a function, and it tends to result in folks not bothering with making sure that they're code works with a particular attribute; they just let attribute inference take care of it all and don't worry about it (in which case, the result is comparable to not having attribute inference in some respects). Another big issue is that when the attributes are inferred, it, becomes _very_ easy to accidentally change which attributes a function has when changing its implementation (similar to how its very easy to accidentally make it so that a function no longer works with CTFE). The primary way to combat that is to use explicit attributes on the unittest blocks which test the function, but that's easy to forget to do, and in a way, it's just moving the explicit attributes from the function itself to the unit tests. So, whether it actually fixes anything is debatable. In general, the cleanest approach is to be as explicit about attributes as possible (which means still using attribute inference with templated functions when the attribute should depend on the template arguments but to not use it much of anywhere else). However, that then requires that you mark up your functions everywhere, which can be very tedious, and many folks don't want to do it. Of course, using more attribute inference reduces that particular problem (which is why many folks want it), but you then get a different set of problems due to the fact that attributes are inferred instead of explicit. So, there's really no winning. In some ways, minimizing attribute inference is the best option, and in others, maximizing it would be better. Probably the best solution to the problem would be to have the defaults better match up with what your average program needs, but no set of defaults fits every program, and different coding styles can result in very different opinions on which set of attributes should be the default. I very much doubt that you would find much of a consensus on it even just within the core set of developers working on dmd, druntime, and Phobos. My guess is that if code breakage were somehow not part of the question that the majority of D programmers would be in favor of safe by default, since the vast majority of code can be safe (though plenty of the time programmers don't bother to mark it as safe), and in theory, only small portions of a program should typically need to be marked as system. But I expect that any other attribute would result in a lot of arguing. For instance, in some respects, pure would be great as the default, but that doesn't interact well at all with stuff like I/O, making it so that you have to write your programs in a certain way for pure to work well for most functions, and not everyone wants to do that. Some folks might want nothrow to be the default, because they don't use exceptions much, but it would be a disaster in code that did use exceptions much. And having const or immutable as the default would be highly controversial. Some folks really want it, but a lot of code simply wouldn't work well that way (including ranges as things currently stand), meaning that a _lot_ of code would have to be marked with mutable (or whatever the attribute would be to undo the default of const or immutable). Some folks might want nothrow to be the default, because they don't use exceptions much, but it would be a disaster in code that did use exceptions much. So, any pretty much any change to the defaults for attributes would likely result in a _lot_ of arguing. The biggest thing that we clearly can do and have talked about from time to time but have never actually done is to introduce a way to reverse attributes that currently can't be reversed - e.g. having something like pure(false). That way, it would become easier to just mark entire modules with an attribute by doing something like safe: at the top. Of course, that would still leave the problem of either not being able to have templated code in that module or needing a way to indicate that an attribute should be inferred for a function instead of using the explicit attribute that's being used on the entire module. So, a DIP on the subject would probably need to worry about fixing that problem, but regardless of the fine details, we really should get a DIP for that at some point here. And it's well-written, with a solid approach to the problem, I fully expect that it would be accepted. It's just that no one has cared enough to write such a DIP. Of course, even if we _did_ have a solution for reversing attributes, slapping an attribute on the top of the module would still potentially be a maintenance problem, because it's then really easy to miss that an attribute is in effect (it's a problem that we've had on several occasions with druntime and Phobos in the few cases where attributes are mass-applied). So, there is no silver bullet here (though regardless of whether mass-applying attributes is something that should ever be considered good practice, we really should add a way to be able to reverse them). - Jonathan M Davis
Dec 18 2018
parent reply Pjotr Prins <pjotr.public12 thebird.nl> writes:
On Tuesday, 18 December 2018 at 11:25:17 UTC, Jonathan M Davis 
wrote:
 Of course, even if we _did_ have a solution for reversing 
 attributes, slapping an attribute on the top of the module 
 would still potentially be a maintenance problem, because it's 
 then really easy to miss that an attribute is in effect (it's a 
 problem that we've had on several occasions with druntime and 
 Phobos in the few cases where attributes are mass-applied). So, 
 there is no silver bullet here (though regardless of whether 
 mass-applying attributes is something that should ever be 
 considered good practice, we really should add a way to be able 
 to reverse them).
Thanks Jonathan for your elaborate explanation. I personally have no problem with the attributes which - in practice - means I don't use them much unless I want to make sure something is nogc, for example. For library designers it makes sense to be explicit. I guess that is where the trade-off kicks in. Maybe it is just a feature. We argue against specifying them because other languages are not as explicit. It does add a little noise.
Dec 18 2018
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, December 18, 2018 6:35:34 AM MST Pjotr Prins via Digitalmars-d-
announce wrote:
 On Tuesday, 18 December 2018 at 11:25:17 UTC, Jonathan M Davis

 wrote:
 Of course, even if we _did_ have a solution for reversing
 attributes, slapping an attribute on the top of the module
 would still potentially be a maintenance problem, because it's
 then really easy to miss that an attribute is in effect (it's a
 problem that we've had on several occasions with druntime and
 Phobos in the few cases where attributes are mass-applied). So,
 there is no silver bullet here (though regardless of whether
 mass-applying attributes is something that should ever be
 considered good practice, we really should add a way to be able
 to reverse them).
Thanks Jonathan for your elaborate explanation. I personally have no problem with the attributes which - in practice - means I don't use them much unless I want to make sure something is nogc, for example. For library designers it makes sense to be explicit. I guess that is where the trade-off kicks in. Maybe it is just a feature. We argue against specifying them because other languages are not as explicit. It does add a little noise.
In practice, library developers are forced to worry about it more, because it affects everyone using their code, whereas within a program, how valuable it is to worry about them depends on the size of the program and what you expect to get out of them. Very large programs can definitely benefit (especially with safe and pure), because it reduces how much code you have to worry about when tracking down the problems that those attributes address, but with small programs, the benefit is far more debatable. And for simple scripts and the like, they're almost certainly a waste of time - which is part of why more restrictive attributes are not the default. It's supposed to be easy to write code that doesn't deal with attributes if you don't want to, but they're there for those who do care. The problem of course is that when you do care, they tend to become a bit of a pain. I confess that I do tend to think about things from the standpoint of a library designer though, in part because I work on stuff like Phobos, but also because I tend to break up my programs into libraries as much as reasonably possible. In general, the more that's in a reusable, easily testable library the better. And with that approach, a lot less of the code for your programs is actually in the program itself, and the attributes tend to matter that much more. - Jonathan M Davis
Dec 18 2018
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Dec 18, 2018 at 06:53:02PM -0700, Jonathan M Davis via
Digitalmars-d-announce wrote:
[...]
 I confess that I do tend to think about things from the standpoint of
 a library designer though, in part because I work on stuff like
 Phobos, but also because I tend to break up my programs into libraries
 as much as reasonably possible. In general, the more that's in a
 reusable, easily testable library the better. And with that approach,
 a lot less of the code for your programs is actually in the program
 itself, and the attributes tend to matter that much more.
[...] My recent programming style has also become very library-like, often with standalone library-style pieces of code budding off a messier, experimental code in main() (and ultimately, if the project is long-lasting, main() itself becomes stripped down to the bare essentials, just a bunch of library components put together). But I've not felt a strong urge to deal with attributes in any detailed way; mostly I just templatize everything and let the compiler do attribute inference on my behalf. For the few cases where explicit attributes matter, I still only use the bare minimum I can get away with, and mostly just enforce template attributes using the unittest idiom rather than bother with writing explicit attributes everywhere in the actual code. T -- He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter
Dec 18 2018
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/13/2018 10:29 AM, Adam D. Ruppe wrote:
 The attribute spam is almost longer than the function itself.
Attributes only start to matter when creating code that will be around for a long time (such as reusable libraries). It's a waste of effort for short term code.
Dec 19 2018
prev sibling parent reply Dgame <r.schuett.1987 gmail.com> writes:
On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe 
wrote:
 The attribute spam is almost longer than the function itself.
I often wished for something like ---- module foo.bar; default( safe, pure); function foo() { } // is annotated with safe & pure deny(pure) // or pure(false) as I suggested a long time ago function bar() { } // is annotated only with safe ---- That would IMO lighten the burden.
Dec 19 2018
parent reply Daniel Kozak <kozzi11 gmail.com> writes:
default(attributes..) is no needed. You can already do this by:

pure  safe:
// your code

But what is needed is some way to disable those attributes.  As you
mentioned  one way could be done by allowing this:

pure(false)  or pure!false or  disable(pure, nogc...)

From implementation point of view it is not hard.  I have already
implemented this before. I have even write some old DIP. But there is new DIP process so someone need to write a new one and need to be able to get it throw new DIP process. And I do not feel I have enough strength to do this right now. =C4=8Dt 20. 12. 2018 8:50 odes=C3=ADlatel Dgame via Digitalmars-d-announce = < digitalmars-d-announce puremagic.com> napsal:
 On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe
 wrote:
 The attribute spam is almost longer than the function itself.
I often wished for something like ---- module foo.bar; default( safe, pure); function foo() { } // is annotated with safe & pure deny(pure) // or pure(false) as I suggested a long time ago function bar() { } // is annotated only with safe ---- That would IMO lighten the burden.
Dec 20 2018
parent Neia Neutuladh <neia ikeran.org> writes:
On Thu, 20 Dec 2018 14:19:33 +0100, Daniel Kozak wrote:
 default(attributes..) is no needed. You can already do this by:
 
 pure  safe:
 // your code
That doesn't work if you have any member functions, and Walter says it's unlikely that that will ever change, even with a DIP. default(pure) would be new syntax with no existing code broken.
Dec 20 2018
prev sibling parent reply Nathan S. <no.public.email example.com> writes:
On Thursday, 13 December 2018 at 10:14:45 UTC, Atila Neves wrote:
 My impression is that it's a consensus that it _should_, but 
 it's not going to happen due to breaking existing code.
I think it would be a bad idea for `immutable` because more often than not it would need to be turned off. I've heard Java called a "BSDM language" because it forces the programmer to type reams of unnecessary characters to accomplish ordinary tasks. This reminds me of that.
Dec 14 2018
parent reply Atila Neves <atila.neves gmail.com> writes:
On Saturday, 15 December 2018 at 02:16:36 UTC, Nathan S. wrote:
 On Thursday, 13 December 2018 at 10:14:45 UTC, Atila Neves 
 wrote:
 My impression is that it's a consensus that it _should_, but 
 it's not going to happen due to breaking existing code.
I think it would be a bad idea for `immutable` because more often than not it would need to be turned off.
Not the case in Rust, not the case in how I write D. TBH it's not such a big deal because something has to be typed, I just default to const now anyway instead of auto. safe and pure though...
Dec 15 2018
next sibling parent Russel Winder <russel winder.org.uk> writes:
On Sat, 2018-12-15 at 19:53 +0000, Atila Neves via Digitalmars-d-announce
wrote:
 On Saturday, 15 December 2018 at 02:16:36 UTC, Nathan S. wrote:
 On Thursday, 13 December 2018 at 10:14:45 UTC, Atila Neves=20
 wrote:
 My impression is that it's a consensus that it _should_, but=20
 it's not going to happen due to breaking existing code.
=20 I think it would be a bad idea for `immutable` because more=20 often than not it would need to be turned off.
=20 Not the case in Rust, not the case in how I write D. TBH it's not=20 such a big deal because something has to be typed, I just default=20 to const now anyway instead of auto. safe and pure though...
Shouldn't be the case in Java either, since it is and always has been a sin= gle assignment supporting language =E2=80=93 it's just that they made mutable t= he default, and trained people not use final. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Dec 17 2018
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote:

  safe and pure though...
Why safe? Can't you just write " safe:" on top and switch to system/ trusted as needed?
Dec 17 2018
next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Monday, 17 December 2018 at 09:41:01 UTC, Dukc wrote:
 On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves 
 wrote:

  safe and pure though...
Why safe? Can't you just write " safe:" on top and switch to system/ trusted as needed?
Argh, I forgot that you are not supposed to safe templates away.
Dec 17 2018
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 12/17/18 4:42 AM, Dukc wrote:
 On Monday, 17 December 2018 at 09:41:01 UTC, Dukc wrote:
 On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote:

  safe and pure though...
Why safe? Can't you just write " safe:" on top and switch to system/ trusted as needed?
Argh, I forgot that you are not supposed to safe templates away.
You can apply safe to anything. It's trusted you have to be careful with. Of course, it probably won't work for many templates. -Steve
Dec 18 2018
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, December 18, 2018 8:00:48 AM MST Steven Schveighoffer via 
Digitalmars-d-announce wrote:
 On 12/17/18 4:42 AM, Dukc wrote:
 On Monday, 17 December 2018 at 09:41:01 UTC, Dukc wrote:
 On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote:
  safe and pure though...
Why safe? Can't you just write " safe:" on top and switch to system/ trusted as needed?
Argh, I forgot that you are not supposed to safe templates away.
You can apply safe to anything. It's trusted you have to be careful with. Of course, it probably won't work for many templates.
safe should only be used on a template if the safety of the code does not depend on the template arguments, and it frequently does depend on them. Mass-applying attributes should rarely be done with templated code. It already causes enough problems with non-templated code, because it's easy to not realize that an attribute has been mass-applied, but without a way to explicitly mark a templated function so that an attribute is inferred in spite of it being mass-applied, mass-applying attributes with templated code will usually result in attributes being wrongly applied. Now, for any attribute other than trusted, the worst that you're going to get out of incorrectly applying an attribute to a template is a compilation error when a particular instantiation doesn't work with that attribute, whereas for trusted it's a disaster in the making. Mass-applying trusted is almost always a terrible idea. The one exception would maybe be something like the bindings in druntime, where a number of modules do it, because it's just a bunch of C prototypes. But even then, there's a high risk of marking a function as trusted later when someone adds it and doesn't realize that trusted was applied. - Jonathan M Davis
Dec 18 2018
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 17 December 2018 at 09:41:01 UTC, Dukc wrote:
 On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves 
 wrote:

  safe and pure though...
Why safe? Can't you just write " safe:" on top and switch to system/ trusted as needed?
Not quite. It doesn't work the way most people expect for member functions and causes problems for templates.
Dec 17 2018
parent Kagamin <spam here.lot> writes:
On Monday, 17 December 2018 at 11:04:13 UTC, Atila Neves wrote:
 Why  safe? Can't you just write " safe:" on top and switch to 
  system/ trusted as needed?
Not quite. It doesn't work the way most people expect for member functions and causes problems for templates.
Don't templates infer attributes? safe didn't work well for trusted aggregates (including inference), not sure if dip1000 fixes that.
Dec 18 2018
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/15/2018 11:53 AM, Atila Neves wrote:
  safe and pure though...
safe is not so hard to adopt, since by using trusted one can proceed incrementally. Going pure, however, is much harder (at least for me) because I'm not used to programming that way. Making a function pure often requires reorganization of how a task is broken up into data structures and functions. For example, https://github.com/dlang/dmd/blob/master/src/dmd/target.d It's nearly all global variables that manipulate other global variables. I recently added a parameter to _init() so that it didn't need to access global.params. Now if the Target.* __gshared's could instead be replaced with fields, then _init() could be made pure.
Dec 17 2018
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Mon, 2018-12-17 at 12:16 -0800, Walter Bright via Digitalmars-d-announce
wrote:
 [=E2=80=A6]
=20
 Going pure, however, is much harder (at least for me) because I'm not use=
d
 to=20
 programming that way. Making a function pure often requires reorganizatio=
n
 of=20
 how a task is broken up into data structures and functions.
=20
 [=E2=80=A6]
I can recommend a short period of working only with Haskell. And then a sho= rt period working only with Prolog. Experience with Java and Python people try= ing to get them to internalise the more declarative approach to software, shows that leaving their programming languages of choice behind for a while is important in improving their use of their languages of choice. For Java people this is quite easy since there is Frege (an implementation = of Haskell on the JVM) and Clojure (a Lisp on the JVM). They do not have to le= ave the comfort of their JVM to get away from Java. On return to Java, people's use of Option<T>, and lambda expressions, etc. was markedly different =E2= =80=93 and a lot more declarative, making testing as well as comprehensibility of their much better. For Python people you have to play slightly different games, such as requir= ing no use of for and while loops, since there is no pure declarative language = on the PVM =E2=80=93 the computational model of the PVM actually makes declara= tive programming quite hard, but it is possible, and it improves code comprehensibility and testability. The problem for people immersed in the C, and C++ world is internalising declarative as a concept. I have tried, and failed a few times, as well as succeeding some. As C++ evolves towards being more and more declarative, it seems hard for the average C++ programmer to really move on from "old style C++", despite all the literature on "modern C++". But as the standards committee drag C++ along the increasingly declarative code route, things change, albeit relatively slowly.=20 Rust I feel has a pivotal role in all this. By emphasising the ML view on mixed declarative and imperative programming, it has found an interesting middle ground that seems to work very well. Many of the C programmers who though C++ overcomplicated and not worth looking at, are taking to Rust and= in doing so leaving C behind. On a personal level, I am now doing most of my programming in Rust rather t= han D, but this is as much to do with the GStreamer community choosing Rust as = the replacement for C for GStreamer. But this is from a library implementers perspective, rather than an application perspective =E2=80=93 but the choic= e pushes through. D (with GtkD and GStreamerD) is in many ways as good a choice as g= tk- rs and gstreeamer-rs for writing applications =E2=80=93 except: =E2=80=93 documentation for gtk-rs and gstreamer-rs is better than for GtkD= and GStreamerD; and =E2=80=93 the standard Rust executor and futures system has been integrated= into gtk- rs, something not present in GtkD. =E2=80=93 GStreamer core developers have an obsessive fear of the word "gar= bage collector". I did a lightning talk at the GStreamer conference in Edinburgh a couple of months ago, concluding that I think D (which about half the audience knew o= f) is overall better than Rust for GTK+ and GStreamer applications, but recognising that Rust is actually the replacement for C and C++ for GTK+ an= d GStreamer applications. (Obviously Python has an ongoing role in all this a= s well.) I think D has missed the opportunity to get significant traction in the GTK= + and GStreamer milieus. :-( =20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Dec 18 2018
next sibling parent reply Kagamin <spam here.lot> writes:
On Tuesday, 18 December 2018 at 08:17:28 UTC, Russel Winder wrote:
 Rust I feel has a pivotal role in all this. By emphasising the 
 ML view on mixed declarative and imperative programming, it has 
 found an interesting middle ground that seems to work very 
 well. Many of the C programmers who though C++ overcomplicated 
 and not worth looking at, are taking to Rust and in doing so 
 leaving C behind.
AIU rust, clojure and prolog are impure.
Dec 18 2018
parent reply Russel Winder <russel winder.org.uk> writes:
On Tue, 2018-12-18 at 09:59 +0000, Kagamin via Digitalmars-d-announce wrote=
:
=20
[=E2=80=A6]
 AIU rust, clojure and prolog are impure.
Clearly Rust is because it allows for mutability, though it is not the default. Clojure is but you have to work hard for that, the initial language is effectively pure. I have no idea how the term impure can be applied to Prolog. =20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Dec 18 2018
parent reply Kagamin <spam here.lot> writes:
On Tuesday, 18 December 2018 at 10:19:14 UTC, Russel Winder wrote:
 Clojure is but you have to work hard for that, the initial 
 language is effectively pure.
https://ideone.com/y8KWja clearly it isn't, its site only claims that most code happens to be pure, but it looks like it's not checked in any way and not sure if purity can be even checked there.
Dec 18 2018
next sibling parent bachmeier <no spam.net> writes:
On Tuesday, 18 December 2018 at 12:20:48 UTC, Kagamin wrote:
 On Tuesday, 18 December 2018 at 10:19:14 UTC, Russel Winder 
 wrote:
 Clojure is but you have to work hard for that, the initial 
 language is effectively pure.
https://ideone.com/y8KWja clearly it isn't, its site only claims that most code happens to be pure, but it looks like it's not checked in any way and not sure if purity can be even checked there.
From the Clojure homepage: "Clojure is impure, yet stands behind the philosophy that programs that are more functional are more robust." The goal is to make it easy to program in a functional style, not to provide a pure functional programming language. It is like OCaml in that respect.
Dec 18 2018
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Tue, 2018-12-18 at 12:20 +0000, Kagamin via Digitalmars-d-announce wrote=
:
 On Tuesday, 18 December 2018 at 10:19:14 UTC, Russel Winder wrote:
 Clojure is but you have to work hard for that, the initial=20
 language is effectively pure.
=20 https://ideone.com/y8KWja clearly it isn't, its site only claims=20 that most code happens to be pure, but it looks like it's not=20 checked in any way and not sure if purity can be even checked=20 there.
Can we all agree that Haskell is a pure functional language. I think we mus= t because: a) it says it is, and b) it is. f2 =3D print "Hello World." f1 =3D f2 main =3D do f1 result of running this: GHCi, version 8.0.1 > "Hello World." > OK so Haskell uses monads and Clojure just uses the JVM I/O. Haskell is pur= e, Clojure is impure. But I stand by my original statement: Clojure is best us= ed as a pure language. Even if I/O is impure, you can make it pure with monads if you really have = to. =20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Dec 18 2018
prev sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
On Tue, 18 Dec 2018 08:17:28 +0000, Russel Winder wrote:
 I did a lightning talk at the GStreamer conference in Edinburgh a couple
 of months ago, concluding that I think D (which about half the audience
 knew of) is overall better than Rust for GTK+ and GStreamer
 applications, but recognising that Rust is actually the replacement for
 C and C++ for GTK+ and GStreamer applications. (Obviously Python has an
 ongoing role in all this as well.)
Is there a video link for that talk? I'd be interested in hearing it.
Dec 18 2018
parent reply Russel Winder <russel winder.org.uk> writes:
On Tue, 2018-12-18 at 16:50 +0000, Neia Neutuladh via Digitalmars-d-announc=
e
wrote:
 On Tue, 18 Dec 2018 08:17:28 +0000, Russel Winder wrote:
 I did a lightning talk at the GStreamer conference in Edinburgh a coupl=
e
 of months ago, concluding that I think D (which about half the audience
 knew of) is overall better than Rust for GTK+ and GStreamer
 applications, but recognising that Rust is actually the replacement for
 C and C++ for GTK+ and GStreamer applications. (Obviously Python has an
 ongoing role in all this as well.)
=20 Is there a video link for that talk? I'd be interested in hearing it.
The videos are here: https://gstconf.ubicast.tv/channels/#gstreamer-conference-2018 I think they recorded the lightning talks as a single video, so you'll have= to fast forward to my little bit. I see from: https://pengutronix.de/de/2018-10-29-gstconf-2018.html That it has been described "an entertaining lightning talk about the histor= y of MeTV, a live TV viewing application, up to the latest rewrite in Rust us= ing GStreamer" --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Dec 18 2018
parent Mike Wey <mike-wey example.com> writes:
On 18-12-2018 19:52, Russel Winder wrote:
 On Tue, 2018-12-18 at 16:50 +0000, Neia Neutuladh via Digitalmars-d-announce
 wrote:
 Is there a video link for that talk? I'd be interested in hearing it.
The videos are here: https://gstconf.ubicast.tv/channels/#gstreamer-conference-2018 I think they recorded the lightning talks as a single video, so you'll have to fast forward to my little bit.
If you are only interested in the MeTV part, this is the start of that lighting talk: https://gstconf.ubicast.tv/permalink/v125ac3127116gnuo89h/#start=2561 -- Mike Wey
Dec 18 2018
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Dec 18, 2018 at 08:17:28AM +0000, Russel Winder via
Digitalmars-d-announce wrote:
 On Mon, 2018-12-17 at 12:16 -0800, Walter Bright via Digitalmars-d-announce
 wrote:
 […]
 
 Going pure, however, is much harder (at least for me) because I'm
 not used to programming that way. Making a function pure often
 requires reorganization of how a task is broken up into data
 structures and functions.
Component-based programming helps a lot in this regard. It breaks the problem down in a way that, when done correctly, captures the essence of the algorithm in a way that's easily translated to pure code (esp. D's expanded definition of purity). [...]
 I can recommend a short period of working only with Haskell. And then
 a short period working only with Prolog. Experience with Java and
 Python people trying to get them to internalise the more declarative
 approach to software, shows that leaving their programming languages
 of choice behind for a while is important in improving their use of
 their languages of choice.
[...] It's all about the mindset. Being forced to think about the problem from a purely functional perspective gives you a radically different perspective from the usual imperative paradigm, and IME often yields insight into the essential structure of your programming problem that is otherwise easily obscured by the imperative structure imposed upon it. T -- Klein bottle for rent ... inquire within. -- Stephen Mulraney
Dec 18 2018
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, December 18, 2018 1:17:28 AM MST Russel Winder via Digitalmars-
d-announce wrote:
 On Mon, 2018-12-17 at 12:16 -0800, Walter Bright via
 Digitalmars-d-announce
 wrote:
 […]

 Going pure, however, is much harder (at least for me) because I'm not
 used to
 programming that way. Making a function pure often requires
 reorganization of
 how a task is broken up into data structures and functions.

 […]
I can recommend a short period of working only with Haskell. And then a short period working only with Prolog. Experience with Java and Python people trying to get them to internalise the more declarative approach to software, shows that leaving their programming languages of choice behind for a while is important in improving their use of their languages of choice.
+1 The only reason that I'm as good at writing functional-style code as I am is because I used Haskell as my goto language for a couple of years towards the end of college. By being forced to program functionally, I got _much_ better at things like recursion, and it significantly improved aspects of my programming in languages like C++ or D. That being said, I think that anyone who programs in such a language longterm by choice has got to be a masochist. Functional programming is a fantastic tool to have in your toolbox, but man does it force you to contort things to make it work in many cases. I've never spent as much time per line of code with any other language as I did with haskell. It's great for stretching your brain but terrible for being productive. I'm sure that folks who always program that way get much better at it, but some problems simply work better with other programming paradigms, and it's fantastic to use a language like D that allows you to program in a variety of paradigms rather than forcing a particular paradigm on you all the time. But without spending a lot of time in a language that forces a particular paradigm, you're likely to be much worse at that particular paradigm in a flexible language such as D. One side effect of having spent as much time as I did with haskell is that I've rarely found the functional nature of D's templates to be much of a problem. Sometimes, it can be, and the addition of static foreach is certainly welcome, but I rarely missed it, because I rarely needed it. The declaritive stuff just tends to fit nicely into the functional paradigm in ways that normal functions often don't. LOL. And it took quite a while before I realized that templates were really a functional language (in fact, I think that I only realized it when I read Bartosz's article on the subject). I just understood how to use them and didn't think about it, though once I did realize it, I felt stupid for not having realized it. - Jonathan M Davis
Dec 18 2018
prev sibling parent reply Nathan S. <no.public.email example.com> writes:
On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote:
 Not the case in Rust, not the case in how I write D. TBH it's 
 not such a big deal because something has to be typed, I just 
 default to const now anyway instead of auto.  safe and pure 
 though...
I'd be interested in seeing some of that Rust code. My impression from Clojure is that an all-immutable style requires leaning heavily on the garbage collector and as far as I know Rust has none.
Dec 18 2018
parent reply Neia Neutuladh <neia ikeran.org> writes:
On Wed, 19 Dec 2018 01:04:24 +0000, Nathan S. wrote:
 On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote:
 Not the case in Rust, not the case in how I write D. TBH it's not such
 a big deal because something has to be typed, I just default to const
 now anyway instead of auto.  safe and pure though...
I'd be interested in seeing some of that Rust code. My impression from Clojure is that an all-immutable style requires leaning heavily on the garbage collector and as far as I know Rust has none.
It is greatly simplified by automatic memory management. Rust doesn't have a GC, but it has a complex ownership system instead, and that's the basis of its memory management. When that's insufficient, you use reference counting. Besides which, this is about defaults. In cases where your data is actually mutable and it would be awkward to switch to a more Haskell-like way of coding, you can still use that.
Dec 18 2018
parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2018-12-19 at 01:45 +0000, Neia Neutuladh via Digitalmars-d-announc=
e
wrote:
 On Wed, 19 Dec 2018 01:04:24 +0000, Nathan S. wrote:
 On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote:
 Not the case in Rust, not the case in how I write D. TBH it's not suc=
h
 a big deal because something has to be typed, I just default to const
 now anyway instead of auto.  safe and pure though...
=20 I'd be interested in seeing some of that Rust code. My impression from Clojure is that an all-immutable style requires leaning heavily on the garbage collector and as far as I know Rust has none.
Rust is garbage collector free. This is why it is appealing to the C (and C= ++) people who think garbage collectors are anathema. Rust has let and let mut to introduce new bindings and variables respective= ly, you have to type less for immutable, which his the right way round. If you want mutability, you have to say so explicitly. Single assignment rocks. :-= ) =20
 It is greatly simplified by automatic memory management. Rust doesn't hav=
e=20
 a GC, but it has a complex ownership system instead, and that's the basis=
=20
 of its memory management. When that's insufficient, you use reference=20
 counting.
With Rust (as with most languages) you have to separate stack and heap allocation. The Rust borrow checker carefully tracks all stack usage and (caveat unsafe activity) will not compile code that has any memory problems that the borrow checker can find. For the heap, Rust provides reference counted pointers which work a lot better than the equivalents in C++: std::shared_ptr and std::unique_ptr can be a right pain. Also of course, unlike C++, Rust has very good support for multi-threading in the language = and the standard library, mostly built around std::Mutex. Rust integrates all t= his with std::Option, std::Error, if let, and match in a way that makes dealing with locks and RAII quite simple. C++ may have brought RAII to mainstream programming, but it's support for multiple threads is still very weak compa= redto D, Rust, Go, etc. =20 [=E2=80=A6] -- Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Dec 18 2018
prev sibling next sibling parent Neia Neutuladh <neia ikeran.org> writes:
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
 I think there’s a general consensus that  safe, pure and 
 immutable should be default.
I recall there was a decent chunk of people around D2.007 who were pushing for const-by-default function parameters on the grounds of if we're going to have this controversial system, we may as well commit to it. Also in the topic of defaults, you could potentially add inout as a default for member functions. It's a lot more strict, but no more so than immutable by default.
Dec 13 2018
prev sibling next sibling parent evilrat <evilrat666 gmail.com> writes:
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
 A few things that have annoyed me about writing D lately:

 https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/
Wait, no word about ref parameters? No way! If you try to bind to typical C++ code they are *EVERYWHERE*, add to that inability to make ref variable(well, it can be mimick'd by wrapping in a helper function but it still sucks) and it completely destroys the usability. In its current form ref in D is PITA... When it comes to C++ interop unfortunatelly it is too much left to wish
Dec 14 2018
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, December 18, 2018 7:02:43 PM MST H. S. Teoh via Digitalmars-d-
announce wrote:
 On Tue, Dec 18, 2018 at 06:53:02PM -0700, Jonathan M Davis via
 Digitalmars-d-announce wrote: [...]

 I confess that I do tend to think about things from the standpoint of
 a library designer though, in part because I work on stuff like
 Phobos, but also because I tend to break up my programs into libraries
 as much as reasonably possible. In general, the more that's in a
 reusable, easily testable library the better. And with that approach,
 a lot less of the code for your programs is actually in the program
 itself, and the attributes tend to matter that much more.
[...] My recent programming style has also become very library-like, often with standalone library-style pieces of code budding off a messier, experimental code in main() (and ultimately, if the project is long-lasting, main() itself becomes stripped down to the bare essentials, just a bunch of library components put together). But I've not felt a strong urge to deal with attributes in any detailed way; mostly I just templatize everything and let the compiler do attribute inference on my behalf. For the few cases where explicit attributes matter, I still only use the bare minimum I can get away with, and mostly just enforce template attributes using the unittest idiom rather than bother with writing explicit attributes everywhere in the actual code.
That works when you're in control of everything and not making libraries public, but it tends to be worse when you're making stuff publicly available, because then there's a much higher risk of accidentally screwing up someone else's code by breaking an attribute. It's also much worse from a documentation standpoint, because users of the library can't look at the documentation to know which attributes are in effect. That's pretty much unavoidable with heavily templated code, but there are generally going to be fewer maintainence problems with a publicly available library if attributes are explicit. And the more heavily used the library is, the more likely it is that there are going to be problems. It's like how if you want your library to be stable with regards to CTFE, you pretty much have to test that CTFE works in your unit tests. It's easy to forget, and ideally, you wouldn't have to worry about it, but if someone else uses your library and uses one of its functions with CTFE, and you then make a change that doesn't work with CTFE and don't realize it, you'll break their code. Ideally, you wouldn't have to worry about ensuring that stuff works with CTFE (after all, D specifically doesn't require that stuff be marked to work with it), but with regards to publicly available libraries, if it's not tested for, it can become a problem. So, arguably, it's best practice to test that stuff works with CTFE (at least in publicly available libraries), but I doubt that all that many libraries actually do it. And attributes are in the same boat in many respects (especially if attribute inference is used heavily). But again, if you're not making stuff publicly available, it's usually easy to just not worry about attributes (or CTFE-ability) except in those cases where you have to or decide that you need to in order to ensure that a particular attribute and its benefits are in effect. It's when you make stuff publicly available that it becomes more of an issue - especially if the library is heavily used. - Jonathan M Davis
Dec 18 2018