If you could make any changes to D, what would they look like?
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Mon Oct 25 17:17:14 UTC 2021
On Monday, 25 October 2021 at 16:13:25 UTC, H. S. Teoh wrote:
> I think the idea behind pure is for the compiler to enforce
> purity in your code, since human beings are prone to making
Strong purity is useful when you use a library that takes a
lambda expression that is meant to be used for comparison and the
like, so you can prove that the library algorithm is correct if
the input expression is strongly pure. D's weak purity does not
seem to even require that the function is idempotent (that it has
the same effect if called twice), so it does not really provide
enough guarantees to verify the correctness of algorithms that
take external code as input. So it isn't surprising that people
have not found much use for it.
Being able to put constraints on lambda-parameters to functions
is very useful in general, but you might want stronger guarantees
than D's «pure».
>> > - 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".
Shared is actually one of the more promising aspects of D where
it could stand out, but you need to be very pedantic when
designing it (theoretical) and make sure that the resulting type
system is sound. Meaning, you cannot allow "convenient hacks" and
"pragmatic exceptions". It remains to be seen if D can adopt
enough strong guarantees (be more principled) to make "shared"
I think it is possible to define shared in a potent manner, that
gives optimization opportunities, but I am not sure if the
majority of D users would embrace it.
> Unfortunately this can't be changed without subtle breakage of
> a whole ton o' code. So, sadly, not gonna happen.
I actually think a lot of things can be changed with
invisible-breakage if you plan for it. All you have to do is to
extend the compiler-internal semantics to accept new features,
without contradicting the old compiler-internal semantics. When
it comes to syntax you could just use a language version
identifier per source file.
> It's convenient for quick-n-dirty concurrent OO code where
> performance isn't critical. But if you want more modern
> concurrent techniques / high performance, yeah, it's not of
> much use. It's arguably dated technology.
Synchronized has runtime debt. That is a higher-level language
design choice and not really a system level design choice. You
could redefine the semantics so you don't have to account for it
in the runtime, I think.
More information about the Digitalmars-d