https://issues.dlang.org/show_bug.cgi?id=8295
--- Comment #14 from anonymous4 <[email protected]> --- (In reply to Marco Leise from comment #13) > No it is not fine, because if we agree that top level qualifiers are free to > change after a copy, and it seems sensible to say that the shared status of > a copy is opt-in, then how would Dlang know that the struct copy should be > destructed with the shared (or const to keep the analogy) destructor? > Against the spec that put shared and const on equal ground, you would have > to force all copies to be shared, too. Implicit conversion for structs without indirection took precedence here. In practice such struct seldom need elaborate management and you can opt out. Though the same argument is true for const too. > It is for example common to enter a critical section that protects some > shared variables and then cast away shared. As a general note you should consider what you do when you implement manual multithreading. It can be also designed in many ways, casting may be not part of the design. > The problem we have understanding each other comes from shared not being > fleshed out. Your complaints are applicable to const too. That would mean const is not fleshed out either? > For me it is a tag that you apply temporarily while data is > _currently_ in use by multiple threads, just so you don't casually read from > or write to it and expect it to work. Implicit casting violates this reasoning. When data used by multiple threads is implicitly casted to thread local, how can it work in your understanding? What will disallow to casually use it? Like for const. If you want shared data to be different, implicit casting erases that difference without a trace, and the point is lost, it becomes C type system where anything converts to anything silently. --
