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