On 2011-09-30 18:07:54 +0000, "Steven Schveighoffer"
<[email protected]> said:
On Fri, 30 Sep 2011 14:00:36 -0400, Michel Fortin
<[email protected]> wrote:
Interesting proposal. You realize if we had a true 'mutable' storage
class for class members it could obey the same rule as you propose in
that bug report: it should be illegal to cast a mutable-containing
object or struct to immutable implicitly. An explicit cast should be
required.
Yes, but the benefit of the proposal is -- it already works in the
current compiler :) You have a monstrous hill to climb to convince
Walter to *add* mutable storage class, but we don't even have to ask
for this one, it works today.
It works today but is unsafe due to the implicit cast. But yeah, lets
use delegates for now.
After the implicit cast is fixed it might be the right time to point
out to Walter that this exception for delegate is no worse than having
a direct mutable keyword. Especially if everyone is using this delegate
detour to achieve what would be simpler and more efficient with
'mutable'.
Also, if we had shared delegates -- delegates which are guarantied to
only manipulate shared data -- we could allow the class that contains a
shared delegate to be implicitly converted to immutable.
I'd like to avoid the complication of having any attributes that apply
to the context pointer. I like how delegates just fit in anywhere, no
matter what the context pointer type is (or its constancy).
But that's no longer true. Delegates no longer fit anywhere with the
fix you just proposed. Only 'shared' delegates would fit anywhere. I
really means *anywhere* since implicitly casting a shared delegate to a
non-shared delegates is a non-issue: it does not change the type of the
variables the context is pointing to.
So basically you'd need to require a shared delegate only where a
normal delegate cannot do the job (like in a class you want to make
immutable, or wanting to pass the delegate across threads).
--
Michel Fortin
[email protected]
http://michelf.com/
