On 30-05-2012 21:10, Andrei Alexandrescu wrote:
On 5/30/12 11:41 AM, Jacob Carlborg wrote:
On Wednesday, 30 May 2012 at 15:45:05 UTC, Andrei Alexandrescu wrote:
On 5/30/12 2:14 AM, Jacob Carlborg wrote:
It seems more and more that D2 is not a designed language. Instead new
features are just slapped on without considering how it would impact
the
rest of the language.
What features are you referring to?
The concurrency model as this thread shows. There is no bridge between
shared and unshared data like const is to immutable and mutable.
We considered that (maybe_synchronized) , but decided not to go with it
amid fear of overcomplicating things.
The result is a feature that is arguably only useful in small laboratory
cases. Are you sure we shouldn't revisit shared and try to work out a
bridge between the unshared and shared world?
Not to mention that shared is fundamentally x86-biased, which seems to
be annoying trend in D development in general...
Perhaps
the monitor on every object should have been removed when the new
concurrency model was designed, as this thread suggests.
This thread does a good job at arguing that scoped locking does not
prevent deadlocks, but this is not new or interesting. Unfortunately I
fail to derive significant proposed value.
There exist type systems that avoid locks. They are very restrictive and
difficult to work with.
I can think of 3 languages that have monitors in the "type" system: D,
C# (as a result of the CLR's design; mostly because they wanted Java
interoperability), and Java. Are you really saying all other type
systems are difficult to work with just because of this little thing?
"inout" was added long after the const system was added to D. If done
correctly this should have come up as a problem when designing the const
system. You cannot apply const/immutable to an object reference in the
same way as you can to a pointer.
"const" doesn't play nice with ranges.
I see how these can be annoying, but they're not the result of us not
designing things. We designed things best we could.
Andrei
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
