DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement

[NoMoreBugs]

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?