Static functions in immutable types...

[Michal Minich]

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()
> {
>     foo();
>     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:

struct S
{
    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*
>> reference.
>>
>> 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 
proposed?

> 
> -Steve

Moved the discussion to digitalmars.D group. please reply there