[OT] Modules dropped out of C++17

[via Digitalmars-d]

On Tuesday, 9 June 2015 at 08:58:19 UTC, Shachar Shemesh wrote:
> but:
> @property void func( ref A a, int b ) ...
>
> should work. Same goes for dropping the () to zero arguments 
> function calls. Once that needs to be a conscious decision by 
> the programmer, my problems with UFCS are greatly reduced 
> (though, to be fair, not completely alleviated).

Yes, that mirrors my thoughts exactly. To me "a.propagate(b,c)" 
reads completely different from "propagate(a,b,c)", just like 
"a.start" and "a.start()" reads different (asking vs doing). I 
want a language to enforce that.

When reading code I don't want to wonder if 
"libraryobject.print()" is a function that is part of an external 
library or if it is application code. I want that to be clear 
when skimming over the source. No IDE can help with that without 
adding clutter.

I therefore find extension-methods are more suitable for objects 
that are self-contained (like integer and string) and less 
suitable for objects that are facades for complicated machinery.  
The module/encapsulation subsystem for language BETA allows local 
extensions by injecting them into library-defined slots in the 
AST.  That way the library author get some control over what you 
can extend.

I also don't add methods much to objects in dynamic languages 
where this is integral to the programming model, only as a quick 
hack. Subclassing is usually the better option. Which is 
reflected in Python by the adding of a new class type with 
restrictions on expanding the type.