www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Static functions in immutable types...

reply =?iso-8859-2?B?VG9tZWsgU293afFza2k=?= <just ask.me> writes:
... don't make sense. So is there a reason why they aren't excluded from  
the "everything in an immutable is immutable" rule?


Tomek
Dec 06 2009
parent reply Michal Minich <michal.minich gmail.com> writes:
Hello Tomek,


 ... don't make sense. So is there a reason why they aren't excluded
 from  the "everything in an immutable is immutable" rule?
 
 Tomek
 


Immutable static member function could be useful...

marking struct or class as const or immutable is the same as marking every 
its member so. The problem I see is in definition of what const or immutable 
member function means:

from D specs: "Immutable member functions are guaranteed that the object 
and anything referred to by the this reference is immutable."

Which applies both to instance and s static functions. I think the above 
definition should apply only to instance functions. Static const or immutable 
functions should  be defined as:

Immutable static member functions are guaranteed that the static variables 
of object and anything referred to by these variables is immutable.

static member function cannot modify member variables already, because they 
do not have this pointer. They would be only allowed to modify its arguments 
and global variables; they would be something like pure functions for the 
congaing type, but not for other world.

I'm not sure how this semantics could be useful in practice, but it seems 
definitely better to me than erroring out on static function inside immutable 
type.
Dec 07 2009
next sibling parent reply =?iso-8859-2?B?VG9tZWsgU293afFza2k=?= <just ask.me> writes:
Dnia 07-12-2009 o 11:34:52 Michal Minich <michal.minich gmail.com>  =

napisa=B3(a):


 Hello Tomek,


 ... don't make sense. So is there a reason why they aren't excluded
 from  the "everything in an immutable is immutable" rule?
  Tomek


 Immutable static member function could be useful...

 marking struct or class as const or immutable is the same as marking  =



 every its member so. The problem I see is in definition of what const =


or  =


 immutable member function means:

 from D specs: "Immutable member functions are guaranteed that the obje=


ct  =


 and anything referred to by the this reference is immutable."

 Which applies both to instance and s static functions. I think the abo=


ve  =


 definition should apply only to instance functions. Static const or  =



 immutable functions should  be defined as:

 Immutable static member functions are guaranteed that the static  =



 variables of object and anything referred to by these variables is  =



 immutable.

 static member function cannot modify member variables already, because=


  =


 they do not have this pointer. They would be only allowed to modify it=


s  =


 arguments and global variables; they would be something like pure  =



 functions for the congaing type, but not for other world.

 I'm not sure how this semantics could be useful in practice, but it  =



 seems definitely better to me than erroring out on static function  =



 inside immutable type.


If by the lot of text above you meant it's a compiler bug, I agree :-)
http://d.puremagic.com/issues/show_bug.cgi?id=3D3598


Tomek
Dec 07 2009
parent Michal Minich <michal.minich gmail.com> writes:
Hello Tomek,


 Dnia 07-12-2009 o 11:34:52 Michal Minich <michal.minich gmail.com>
 napisał(a):
 

 Hello Tomek,
 

 ... don't make sense. So is there a reason why they aren't excluded
 from  the "everything in an immutable is immutable" rule?
 Tomek


 Immutable static member function could be useful...
 
 marking struct or class as const or immutable is the same as marking
 every its member so. The problem I see is in definition of what const
 or  immutable member function means:
 
 from D specs: "Immutable member functions are guaranteed that the
 object  and anything referred to by the this reference is immutable."
 
 Which applies both to instance and s static functions. I think the
 above  definition should apply only to instance functions. Static
 const or  immutable functions should  be defined as:
 
 Immutable static member functions are guaranteed that the static
 variables of object and anything referred to by these variables is
 immutable.
 
 static member function cannot modify member variables already,
 because  they do not have this pointer. They would be only allowed to
 modify its  arguments and global variables; they would be something
 like pure  functions for the congaing type, but not for other world.
 
 I'm not sure how this semantics could be useful in practice, but it
 seems definitely better to me than erroring out on static function
 inside immutable type.
 


 If by the lot of text above you meant it's a compiler bug, I agree :-)
 http://d.puremagic.com/issues/show_bug.cgi?id=3598
 
 Tomek
 


I'm glad we agreed it is a bug :-)

How about the semantics I proposed ? If you agree I would include it in the 
bug text.
Dec 08 2009
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 07 Dec 2009 05:34:52 -0500, Michal Minich  
<michal.minich gmail.com> wrote:


 Hello Tomek,


 ... don't make sense. So is there a reason why they aren't excluded
 from  the "everything in an immutable is immutable" rule?
  Tomek


 Immutable static member function could be useful...

 marking struct or class as const or immutable is the same as marking  
 every its member so. The problem I see is in definition of what const or  
 immutable member function means:

 from D specs: "Immutable member functions are guaranteed that the object  
 and anything referred to by the this reference is immutable."

 Which applies both to instance and s static functions. I think the above  
 definition should apply only to instance functions. Static const or  
 immutable functions should  be defined as:

 Immutable static member functions are guaranteed that the static  
 variables of object and anything referred to by these variables is  
 immutable.


Let's say there was an immutable static member function which treated the  
static data members as immutable.  This means nobody else can change  
them.  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.

-Steve
Dec 08 2009
parent reply Michal Minich <michal.minich gmail.com> writes:
Hello Steven,

I'm sorry, but have big trouble to understand what you want to say. So I 
will comment to what I can, and try to rephrase my post.


 On Mon, 07 Dec 2009 05:34:52 -0500, Michal Minich
 <michal.minich gmail.com> wrote:
 

 Hello Tomek,
 

 ... don't make sense. So is there a reason why they aren't excluded
 from  the "everything in an immutable is immutable" rule?
 Tomek


 Immutable static member function could be useful...
 
 marking struct or class as const or immutable is the same as marking
 every its member so. The problem I see is in definition of what const
 or  immutable member function means:
 
 from D specs: "Immutable member functions are guaranteed that the
 object  and anything referred to by the this reference is immutable."
 
 Which applies both to instance and s static functions. I think the
 above  definition should apply only to instance functions. Static
 const or  immutable functions should  be defined as:
 
 Immutable static member functions are guaranteed that the static
 variables of object and anything referred to by these variables is
 immutable.
 


 Let's say there was an immutable static member function which treated
 the  static data members as immutable.  This means nobody else can
 change  them.  


Couldn't they be changed from outside of the type?


 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?

 
 -Steve
 


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?
Dec 08 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 08 Dec 2009 11:53:03 -0500, Michal Minich  
<michal.minich gmail.com> wrote:


 Hello Steven,

 I'm sorry, but have big trouble to understand what you want to say. So I  
 will comment to what I can, and try to rephrase my post.


 On Mon, 07 Dec 2009 05:34:52 -0500, Michal Minich
 <michal.minich gmail.com> wrote:


 Hello Tomek,


 ... don't make sense. So is there a reason why they aren't excluded
 from  the "everything in an immutable is immutable" rule?
 Tomek


 Immutable static member function could be useful...
  marking struct or class as const or immutable is the same as marking
 every its member so. The problem I see is in definition of what const
 or  immutable member function means:
  from D specs: "Immutable member functions are guaranteed that the
 object  and anything referred to by the this reference is immutable."
  Which applies both to instance and s static functions. I think the
 above  definition should apply only to instance functions. Static
 const or  immutable functions should  be defined as:
  Immutable static member functions are guaranteed that the static
 variables of object and anything referred to by these variables is
 immutable.


 Let's say there was an immutable static member function which treated
 the  static data members as immutable.  This means nobody else can
 change  them.


 Couldn't they be changed from outside of the type?


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 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.

-Steve
Dec 08 2009
parent Michal Minich <michal.minich gmail.com> writes:
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
Dec 08 2009