On Sunday, 4 November 2018 at 15:40:03 UTC, Neia Neutuladh wrote:
There are many potential features that wouldn't cause problems
in isolation. Should we add all of them? Obviously not; the
result would be a horribly complex language that takes too much
time to learn and is impossible to maintain.
So instead, we need to aggressively filter out potential added
features to ensure that what they add is sufficiently important
to justify later maintenance costs and the effort of learning
things.
The justification for this feature rests on real-world examples
of bugs that have been caused by its lack.
You keep turning this argument around, as though it is a request
to change D.
We should be able to have a discussion, about ways to further
improve type safety inside a module, without being constantly
taunted by your hyperbole.
The discussion might even lead to ways to help programmers
address the issues being raised, that don't require a change to D
(and I don't mean 'just put your class/struct in it's own
module').
Now, the fact is, that the D module is a conglomeration of
different types.
None of the types declared within a module has any independence
from any other type, within the module. Fact.
Some clearly think this is a good thing. Fine, you have it that
way already. That will never change.
But some think this requires an undue burden on the part of the
programmer to be extra vigiliant around how they compose their
types. Sure a few lines in module, you can easily do that. But as
the number of line increase, so would the chances of you doing
something you never intended to do. There is no way the
programmer to provide a guarantee around the use of a type, from
other code in the module, since the data and methods in any type
are mutable from outside that type.
Some think this shared mutability between types within a module,
can lead to bugs and unsafe behaviour.
Some think it might be nice, if the programmer had a means to
provide better guarantees for the their declared types.
Type safety is an important and critical component in software
architecture.
It's not something you should 'agressively filter out' from
discussion.
Whether the language could handle a change to address this, would
be a further stage of the discussion. From what I hear, it may
not be able to handle such a change, and the D module is doomed
to be what it is, and programmers will bear the responsibilty for
type safety within a module.
