On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
I propose an idea, for discussion (robust discussion even
better ;-)
Add an new attribute to class, named 'sealed'.
No, not sealed as in Scala.
No, not sealed as in C#
sealed as in oxford dictionary (close securely, non-porous).
when sealed is applied on the class, this means the class is
sealed.
the sealed attribute only makes sense within a module, and
affects nothing outside of the module.
When sealed is applied to the class, then, interfacing to a
class within a module, from code outside that class - but still
within the module, can now only occur via the published
interface of the class.
outside code in the module, can no longer directly access your
private parts!
The class is sealed.
I don't think that "sealed" is the right name here. Currently C#
has its sealed and Scala has its sealed - and these are different
things (although I don't code C# and may be wrong, it seems like
C#'s sealed is Java's or D's final). I believe that giving
"sealed" keyword yet another sense in D is not the right approach.
Furthermore, I don't believe that the proposed version of sealed
would be a widely-used feature that broadens the language
capabilities. It solves the problem that - as discussion in my
thread shown - some people consider valid, and some not.
My opinion is that it's not worth a new keyword and time for
implementing. In the same manner you could ask for removing
friend concept from C++ as a bad concept. I don't answer the
question whether this concept is good or bad - just give an
example. The difference is that you can just go without friend at
all, and module-level private is forced.
The other reason I don't think it is a feature significant enough
is kind of library level. I expect that only author or limited
team of people will freely modify the code of module. So there is
limited number of people that have a control over the module and
it shouldn't be a big deal not to refer to private fields outside
the class or define it as a team rule. I believe that a nice
approach here would be to add a check to DScanner, so that your
editor or IDE could optionally warn you if you refer to the
private member from outside the class. But as module is a small
unit and its code should probably be controlled/verified by the
limited number of people, I don't see this as a big deal.
Note that Scala-like sealed from my proposal would have a greater
impact (it blocks inheritance outside the module - helps to
prevent the library code from being used in a way it is not
designed to) and your proposal changes things in a very limited
scope.
OFC, I am not a "compiler person", nor Walter, Andrei and anyone
from the team, so my opinion is definitely not decisive in any
way :)
To sum up [TLDR]: I don't see your arguments strong enough to
alter the language (especially make a cross-language confusion
over the "sealed" keyword), but DScaner check would still allow
to track down what you consider bad.
