On Friday, 8 April 2022 at 17:28:30 UTC, Timon Gehr wrote:>
On 08.04.22 17:07, Zach Tollen wrote:>
On Friday, 8 April 2022 at 08:23:34 UTC, Timon Gehr wrote:>
Yes. I do not understand why so many people are so keen to conflate entirely different things into the same concepts. That's just bad language design.
No it's not.
Of course it is. It hampers expressiveness while adding incidental complexity. Lose-lose.
Wrong. Simplicity is fine when it allows you to do what you want without forcing you to do what you don't want. If what you say were true, then D should have adopted every single built-in attribute and every type qualifier which has ever been suggested, because the lack of them would "hamper expressiveness."
The incidental complexity of a given multi-purpose feature only arises when the one purpose of the feature simultaneously makes another purpose of the same feature difficult to achieve. I do not consider this an inevitable outcome. I want to examine the specific case instead.> >
But it's also bad language design not to be open to the possibility of a conflation of different things which ends up being harmonious and easy to explain.
That's just never how it works out. You should only conflate things that are actually the same thing.
The use cases of DIP1035, for the most part, are a strict subset of the uses of
__metadata. It is agreed that you can only access
__metadata variables from
@system code. Therefore by implementing
__metadata you basically get DIP1035 for free. My proposal is simply to use DIP1035's word
@system two encompass the two ideas.
The purpose of DIP1035 is to be able to force a variable to be considered unsafe, because it is already being used in an unsafe way. If you're trying to decide whether merging
__metadata is a good idea, you would first need to come up with a use case proving a possible conflict of purposes as follows:
You would need to show how marking a variable
@system because it is already being used dangerously might then lead to it being used dangerously differently, but now in an unintended and undesirable way, solely because before, when it was used dangerously, it was immutable.
It seems like a really tall order to me. And if you can't provide an example like that, then on what basis can you say that these two features can't be combined?
My main point is that mutability, in nearly all cases, is precisely what would motivate a variable to require being marked
@system. As to global data which is initialized to unsafe values and therefore inferred
@system, I don't even know what these would be for. They seem like they would always be bugs to me.