www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - struct init() method

reply bearophile <bearophileHUGS lycos.com> writes:
This program comes from a reduction of a bug I've found:


struct Foo {
    void init() {}
}
void main() {
    Foo*[] foos;
    //(*foos[0]).init(); // OK
    foos[0].init(); // Error: function expected before (), not null of type Foo*
}


What do you think about the idea of not allowing methods named init() in
structs? (Especially if they are a  property). Or maybe there is a better
solution, opinions welcome.

Bye,
bearophile
Feb 24 2012
next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 25-02-2012 05:05, bearophile wrote:

 This program comes from a reduction of a bug I've found:


 struct Foo {
      void init() {}
 }
 void main() {
      Foo*[] foos;
      //(*foos[0]).init(); // OK
      foos[0].init(); // Error: function expected before (), not null of type
Foo*
 }


 What do you think about the idea of not allowing methods named init() in
structs? (Especially if they are a  property). Or maybe there is a better
solution, opinions welcome.

 Bye,
 bearophile


IMHO we shouldn't allow having *any* members that use the same name as 
any of the compiler-provided properties/functions.

-- 
- Alex
Feb 25 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Feb 25, 2012 at 01:23:21PM +0100, Alex Rønne Petersen wrote:

 On 25-02-2012 05:05, bearophile wrote:

This program comes from a reduction of a bug I've found:


struct Foo {
     void init() {}
}
void main() {
     Foo*[] foos;
     //(*foos[0]).init(); // OK
     foos[0].init(); // Error: function expected before (), not null of type
Foo*
}


What do you think about the idea of not allowing methods named init() in
structs? (Especially if they are a  property). Or maybe there is a better
solution, opinions welcome.

Bye,
bearophile


 
 IMHO we shouldn't allow having *any* members that use the same name
 as any of the compiler-provided properties/functions.


[...]

Agreed.


T

-- 
Marketing: the art of convincing people to pay for what they didn't need
before which you can't deliver after.
Feb 25 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/25/2012 04:52 PM, H. S. Teoh wrote:

 On Sat, Feb 25, 2012 at 01:23:21PM +0100, Alex Rønne Petersen wrote:

 On 25-02-2012 05:05, bearophile wrote:

 This program comes from a reduction of a bug I've found:


 struct Foo {
      void init() {}
 }
 void main() {
      Foo*[] foos;
      //(*foos[0]).init(); // OK
      foos[0].init(); // Error: function expected before (), not null of type
Foo*
 }


 What do you think about the idea of not allowing methods named init() in
structs? (Especially if they are a  property). Or maybe there is a better
solution, opinions welcome.

 Bye,
 bearophile


 IMHO we shouldn't allow having *any* members that use the same name
 as any of the compiler-provided properties/functions.


 [...]

 Agreed.


 T


This is useful:

struct S{
      disable enum init = 0;
}
Feb 25 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, February 25, 2012 17:07:14 Timon Gehr wrote:

 This is useful:
 
 struct S{
       disable enum init = 0;
 }


I thought that the way that you were supposed to do that was

 disable this();

- Jonathan M Davis
Feb 25 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 26-02-2012 00:18, Jonathan M Davis wrote:

 On Saturday, February 25, 2012 17:07:14 Timon Gehr wrote:

 This is useful:

 struct S{
        disable enum init = 0;
 }


 I thought that the way that you were supposed to do that was

  disable this();

 - Jonathan M Davis


Yeah, I'm not sure what purpose the other example serves.

-- 
- Alex
Feb 25 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Feb 26, 2012 at 12:23:47AM +0100, Alex Rønne Petersen wrote:

 On 26-02-2012 00:18, Jonathan M Davis wrote:

On Saturday, February 25, 2012 17:07:14 Timon Gehr wrote:

This is useful:

struct S{
       disable enum init = 0;
}


I thought that the way that you were supposed to do that was

 disable this();

- Jonathan M Davis


 
 Yeah, I'm not sure what purpose the other example serves.


[...]

It serves to prove that we need to disallow 'init' as a member name. :-)


T

-- 
Skill without imagination is craftsmanship and gives us many useful
objects such as wickerwork picnic baskets.  Imagination without skill
gives us modern art. -- Tom Stoppard
Feb 25 2012
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, February 25, 2012 17:54:44 H. S. Teoh wrote:

 On Sun, Feb 26, 2012 at 12:23:47AM +0100, Alex R=C3=B8nne Petersen wr=


ote:

 On 26-02-2012 00:18, Jonathan M Davis wrote:

On Saturday, February 25, 2012 17:07:14 Timon Gehr wrote:

This is useful:

struct S{

       disable enum init =3D 0;

}


I thought that the way that you were supposed to do that was

 disable this();

- Jonathan M Davis


=20
 Yeah, I'm not sure what purpose the other example serves.


=20
 [...]
=20
 It serves to prove that we need to disallow 'init' as a member name. =


:-)

No. I think that he meant that he doesn't know what purpose

 disable enum init =3D 0;

serves given that

 disable this();

already disables the init property. The fact that you're able to overri=
de init=20
is a separate, albeit related issue. But yes, it should be disallowed t=
o=20
declare any symbol as a member of a struct or class with the name init.=


- Jonathan M Davis
Feb 25 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 26-02-2012 02:54, Jonathan M Davis wrote:

 On Saturday, February 25, 2012 17:54:44 H. S. Teoh wrote:

 On Sun, Feb 26, 2012 at 12:23:47AM +0100, Alex Rønne Petersen wrote:

 On 26-02-2012 00:18, Jonathan M Davis wrote:

 On Saturday, February 25, 2012 17:07:14 Timon Gehr wrote:

 This is useful:

 struct S{

        disable enum init = 0;

 }


 I thought that the way that you were supposed to do that was

  disable this();

 - Jonathan M Davis


 Yeah, I'm not sure what purpose the other example serves.


 [...]

 It serves to prove that we need to disallow 'init' as a member name. :-)


 No. I think that he meant that he doesn't know what purpose

  disable enum init = 0;

 serves given that

  disable this();

 already disables the init property. The fact that you're able to override init
 is a separate, albeit related issue. But yes, it should be disallowed to
 declare any symbol as a member of a struct or class with the name init.

 - Jonathan M Davis


Yep, exactly.

-- 
- Alex
Feb 25 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/26/2012 12:18 AM, Jonathan M Davis wrote:

 On Saturday, February 25, 2012 17:07:14 Timon Gehr wrote:

 This is useful:

 struct S{
        disable enum init = 0;
 }


 I thought that the way that you were supposed to do that was

  disable this();

 - Jonathan M Davis


struct S{ disable this();}
void main(){S s = S.init;}
Feb 26 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, February 26, 2012 12:48:06 Timon Gehr wrote:

 On 02/26/2012 12:18 AM, Jonathan M Davis wrote:

 On Saturday, February 25, 2012 17:07:14 Timon Gehr wrote:

 This is useful:
 
 struct S{
 
        disable enum init = 0;
 
 }


 
 I thought that the way that you were supposed to do that was
 
  disable this();
 
 - Jonathan M Davis


 
 struct S{ disable this();}
 void main(){S s = S.init;}


Well, that's a problem then. It looks like it's bug - either that or I 
completely misunderstood what was going on with  disable and structs.

- Jonathan M Davis
Feb 26 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 26-02-2012 12:53, Jonathan M Davis wrote:

 On Sunday, February 26, 2012 12:48:06 Timon Gehr wrote:

 On 02/26/2012 12:18 AM, Jonathan M Davis wrote:

 On Saturday, February 25, 2012 17:07:14 Timon Gehr wrote:

 This is useful:

 struct S{

         disable enum init = 0;

 }


 I thought that the way that you were supposed to do that was

  disable this();

 - Jonathan M Davis


 struct S{ disable this();}
 void main(){S s = S.init;}


 Well, that's a problem then. It looks like it's bug - either that or I
 completely misunderstood what was going on with  disable and structs.

 - Jonathan M Davis


IMHO .init should yield an error for structs with  disable this(). 
Anything else seems illogical.

-- 
- Alex
Feb 26 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, February 26, 2012 13:15:51 Alex R=C3=B8nne Petersen wrote:

 On 26-02-2012 12:53, Jonathan M Davis wrote:

 On Sunday, February 26, 2012 12:48:06 Timon Gehr wrote:

 On 02/26/2012 12:18 AM, Jonathan M Davis wrote:

 On Saturday, February 25, 2012 17:07:14 Timon Gehr wrote:

 This is useful:
=20
 struct S{
=20
         disable enum init =3D 0;
=20
 }


=20
 I thought that the way that you were supposed to do that was
=20
  disable this();
=20
 - Jonathan M Davis


=20
 struct S{ disable this();}
 void main(){S s =3D S.init;}


=20
 Well, that's a problem then. It looks like it's bug - either that o=




r I

 completely misunderstood what was going on with  disable and struct=




s.

=20
 - Jonathan M Davis


=20
 IMHO .init should yield an error for structs with  disable this().
 Anything else seems illogical.


Well, like I said, it's my understanding that  disable this() is the wa=
y that=20
you're supposed to disable .init - as in that's the whole point of havi=
ng=20
added  disable this() to the language (though it can also be used to ma=
ke=20
classes unconstructable). So, either my understanding is wrong and/or t=
his is=20
a bug.

- Jonathan M Davis
Feb 26 2012
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 25.02.2012 8:05, bearophile wrote:

 This program comes from a reduction of a bug I've found:


 struct Foo {
      void init() {}
 }
 void main() {
      Foo*[] foos;
      //(*foos[0]).init(); // OK
      foos[0].init(); // Error: function expected before (), not null of type
Foo*
 }


 What do you think about the idea of not allowing methods named init() in
structs? (Especially if they are a  property). Or maybe there is a better
solution, opinions welcome.

 Bye,
 bearophile


FWIW I've encountered this thingy while messing with phobos std.file 
around a year ago. Still allowed and mishandled it seems.

-- 
Dmitry Olshansky
Feb 25 2012