If you could make any changes to D, what would they look like?
IGotD-
nise at nise.com
Mon Oct 25 14:34:24 UTC 2021
On Monday, 25 October 2021 at 13:42:19 UTC, Guillaume Piolat
wrote:
>
> It's a great thing other people get to decide, because I would
> remove:
> - pure
> - shared
> - @property
> - inout
> - GC-calling-destructors
> - virtual-by-default
> - real
> - synchronized
> - inout
> - alias this
> - and parts of Phobos too.
>
> But D is also about catering to many different people.
Finally a post that made me wake up from my sleep. Interesting I
agree with most of it.
> - pure
Agreed, if you don't want a function messing around with a global
state, don't mess around with a global state, easy. You don't
need a badge for that. I'm sure there are holes in the pure rule
that the compiler cannot detect as well.
> - shared
Agreed, shared is one of the biggest mess in D. This is where it
is obvious where the D language designers lack in experience and
knowledge. It is also a very complex issue so my advice is to
rather to copy an existing design or not at all and rely more on
manual concurrent "safety".
> - @property
Do we need it? Isn't this partly handled by UFCS.
> - inout
Isn't this depreciated?
> - GC-calling-destructors
GC calling destructors is often not used. However, there might be
rare occasions we need it. Like knowing when something is being
destroyed.
> - virtual-by-default
Agreed, it should be final by default. This one of the rare
occasions where the D maintainers agree.
> - real
Agreed, real can be removed. Even Intel doesn't optimize their
old FPU anymore and SSE is used instead. There might be rare
occasions where we should use old Intel FPU, like embedded
Pentium clones but these are rare themselves.
> - synchronized
I kind of like the idea with synchronized classes. I don't think
it is that hard to implement and could be a neat thing. Also
helps Java portability.
> - alias this
Agreed, alias this should be removed and mixin templates should
be used instead.
> - and parts of Phobos too.
You have to be more specific about this one.
More information about the Digitalmars-d
mailing list