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.

Reply via email to