On Tuesday, 13 November 2018 at 07:13:01 UTC, NoMoreBugs wrote:
You nailed it on the head.
The only sensible course of action, therefore, is to give
programmers the option to disable implicit conversions,
completely (or if doable, more precisely).
And while you're thinking about how to do that, can you also
please think about how to give the programmer the option to
enforce privacy on variable/method within a module.
Programmers just want to be able to write code that is more
likely to be correct, than not, and have the compiler catch it
when it's not.
You want to attract such programmers, or not?
ok...not such a great idea (the compiler switch), after I thought
more about that idea.
but some sort of annotation, and the programmers intent could
become *much* clearer (allowing the programmer - and those
reading it - to better reason about the correctness of the code):
bool(this) b; // compiler not allowed to do implicit conversions
when assigning on b
double(this) d; // compiler not allowed to do implicit
conversions when assigning to d
class C //(or struct)
{
private(this) password; // compiler will not allow other code
outside of this type,
// (but in the same module) to directly
access password.
}
i.e (this) is just an annotation, for saying:
"I own this type, and the type needs to stay the way it's defined
- no exceptions".
Too much? The language could not handle it? The programmer would
never want it?
