Static functions in immutable types...
michal.minich at gmail.com
Tue Dec 8 10:35:32 PST 2009
On Tue, 08 Dec 2009 12:23:53 -0500, Steven Schveighoffer wrote:
> That would be a violation of immutability. If they can change, then
> they are not immutable. Note they cannot be "temporarily" immutable,
> they are immutable from the moment that something casts it to immutable.
> It is up to you, the programmer, to ensure that no mutable references
> exist after you perform the cast. Using a mutable reference to
> immutable data results in undefined behavior.
> To illustrate:
> int x;
> immutable(int) *y;
> void foo()
> y = cast(immutable(int)*)&y; // no longer allowed to use x!
> void bar()
> x++; // undefined behavior!
This is misunderstanding, I'm talking about interaction of mutable static
data members with immutable static member function, as in this example:
static int x;
static void foo () immutable
// x = 3; // should be error, because immutable static member
function cannot change mutable static data members.
>>> This means that there cannot be any static member functions that are
>>> not immutable. This means that the data members cannot be marked as
>>> public unless they are also marked as immutable.
>>> In this case, the equivalent thing is to mark all static data members
>>> as immutable, and leave the static function as a normal function.
>>> This is why the OP said they "don't make sense" Although his
>>> statement really should be "immutable static functions don't make
>>> sense", not "static functions in immutable types don't make sense,"
>>> as they do make sense, they should just not be marked as immutable.
>>> The bug filed is absolutely a bug, it should be possible to have a
>>> normal static function inside an immutable type.
>> Currently everything is marked as immutable in immutable type. Do you
>> think it is good to have exception for static function?
> Either you make an exception for a static function -or- applying
> immutable to a static function is a no-op. There is no reason to
> restrict immutable types from having static functions.
>> So to rephrase:
>> 1. from D specs: " A struct declaration can have a storage class of
>> const, immutable or shared. It has an equivalent effect as declaring
>> each member of the struct as const, immutable or shared." -- I'm ok
>> with this, it is simple.
>> 2. from D specs: "Immutable member functions are guaranteed that the
>> object and anything referred to by the this reference is immutable." --
>> this rule is wrong, because it mentions *this* and at the same time it
>> applies to static member functions, which obviously doesn't have *this*
>> 3. I propose changing rule in point 2 to: "Immutable *non-static*
>> member functions are guaranteed that the object and anything referred
>> to by the this reference is immutable." and adding this one: "Immutable
>> static member functions are guaranteed that the static variables of
>> object and anything referred to by these variables is immutable"
>> And I'm asking if the change is reasonable - Or how should be defined
>> semantics of static immutable member function?
> static immutable member functions are either illegal in the case where
> all static member data is not immutable or equivalent to static member
> functions in the case where all the member data is immutable.
> I agree the rule needs to change, here is how I would change it:
> A struct declaration can have a storage class of const, immutable or
> shared. It has an equivalent effect as declaring each member of the
> struct except static functions as const, immutable or shared.
> Immutable/const/shared non-static member functions are guaranteed that
> the object and anything referred to by the this reference is
> immutable/const/shared. Declaring a static member function is
> immutable/const/shared is considered an error.
The change I proposed is in at least line with existing functionality.
What is a benefit of not having immutable member functions as you
Moved the discussion to digitalmars.D group. please reply there
More information about the Digitalmars-d-learn