On Thursday, 23 August 2018 at 09:26:46 UTC, rikki cattermole
wrote:
On 23/08/2018 9:09 PM, Shachar Shemesh wrote:
functions may be @safe, nothrow, @nogc, pure. If it's a method
it might also be const/inout/immutable, static. The number of
libraries that support all combinations is exactly zero (e.g.
- when passing a delegate in).
Indeed that combination is horrible. It does deserve a rethink,
but it probably doesn't warrant changing for a little while
since its more of a polishing than anything else (IMO anyway).
I think that tends to be where D's biggest failing tends to be is
the polish.
I started using D before these features existed, I also continue
to use despite these features existing, like many I try to use
them but end up falling back to not. But these things tend to be
a big part of the D marketing.
I would classify the --dip1000 work as a polishing effort, but it
also opens the doors to more areas that need polish, and most
likely won't get it before --dip1000 is considered done.
I would also disagree with the community being hostile to
criticism. Explanation and workarounds are usually given, not
hostility. There is a huge resistance to change, but that should
be expected and continue to increase. It is usually just sad how
long it takes for change to happen when it needs to.
Tangent:
Sem versions may be easy to implement, but they have no value
without practice. Practice isn't so easy to manage. We may not be
following the sem version spec but it wouldn't add value to
current practice. There is a patch release and there is a
breaking changes and feature release. If we don't get the
management of breaking changes correct, sem versioning is broken
anyway.
