Wed Oct 17 - Avoiding Code Smells by Walter Bright

[commonGripes]

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.