What will the following code print? Do not use the compiler:

import std.stdio;

struct A {
	int a = 1;

	void initialize() {
		a = a.init;
	}
}

void main() {
	A a;
	a.initialize();

	writeln(a.a);
}

I find this behavior unexpected.

On Sunday, 28 January 2018 at 06:25:51 UTC, Shachar Shemesh wrote:
> What will the following code print? Do not use the compiler:
>
> import std.stdio;
>
> struct A {
> 	int a = 1;
>
> 	void initialize() {
> 		a = a.init;
> 	}
> }
>
> void main() {
> 	A a;
> 	a.initialize();
>
> 	writeln(a.a);
> }
>
> I find this behavior unexpected.

Works exactly as I predicted.

On 01/27/2018 10:25 PM, Shachar Shemesh wrote:
> What will the following code print? Do not use the compiler:
> 
> import std.stdio;
> 
> struct A {
>      int a = 1;
> 
>      void initialize() {
>          a = a.init;
>      }
> }
> 
> void main() {
>      A a;
>      a.initialize();
> 
>      writeln(a.a);
> }
> 
> I find this behavior unexpected.

I used the compiler to check my guess and I was wrong. The following makes the difference:

        a = A.init.a;

So we currently have:

    a.init          (type's init value)
    A.init.a        (members' init value)

If it were designed as you want, we would have the following:

    typeof(a).init  (type's init value)
    a.init          (members init value)

Well, too late I guess. :)

Ali

On 28/01/18 08:33, Mike Franklin wrote:
> On Sunday, 28 January 2018 at 06:25:51 UTC, Shachar Shemesh wrote:
>> What will the following code print? Do not use the compiler:
>>
>> import std.stdio;
>>
>> struct A {
>>     int a = 1;
>>
>>     void initialize() {
>>         a = a.init;
>>     }
>> }
>>
>> void main() {
>>     A a;
>>     a.initialize();
>>
>>     writeln(a.a);
>> }
>>
>> I find this behavior unexpected.
> 
> Works exactly as I predicted.

Good for you.

I think the compiler should warn about such a case.

why is `a.init` even legal? (instead of typeof(a).init)
likewise the following compiles, but IMO should not:
class A{ void fun(this a){}}
(instead we should have typeof(this)

How about deprecating these lax syntaxes?
they serve no purpose (we should use typeof(...)) and can cause harm
in generic code

On Sat, Jan 27, 2018 at 10:39 PM, Ali Çehreli via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 01/27/2018 10:25 PM, Shachar Shemesh wrote:
>>
>> What will the following code print? Do not use the compiler:
>>
>> import std.stdio;
>>
>> struct A {
>>      int a = 1;
>>
>>      void initialize() {
>>          a = a.init;
>>      }
>> }
>>
>> void main() {
>>      A a;
>>      a.initialize();
>>
>>      writeln(a.a);
>> }
>>
>> I find this behavior unexpected.
>
>
> I used the compiler to check my guess and I was wrong. The following makes the difference:
>
>         a = A.init.a;
>
> So we currently have:
>
>     a.init          (type's init value)
>     A.init.a        (members' init value)
>
> If it were designed as you want, we would have the following:
>
>     typeof(a).init  (type's init value)
>     a.init          (members init value)
>
> Well, too late I guess. :)
>
> Ali

On Sunday, January 28, 2018 08:25:51 Shachar Shemesh via Digitalmars-d wrote:
> What will the following code print? Do not use the compiler:
>
> import std.stdio;
>
> struct A {
>   int a = 1;
>
>   void initialize() {
>       a = a.init;
>   }
> }
>
> void main() {
>   A a;
>   a.initialize();
>
>   writeln(a.a);
> }
>
> I find this behavior unexpected.

It does exactly what I'd expect it to do, though honestly, it's the sort of thing I wish weren't legal, just like I wish that it weren't legal to call a static member function via a member. Maybe there are cases where it's useful, but it just seems wrong.

In any case, init goes with a type, not a variable, which is why it acts the way it does.

- Jonathan M Davis

On Saturday, January 27, 2018 23:44:40 Jonathan M Davis via Digitalmars-d wrote:
> On Sunday, January 28, 2018 08:25:51 Shachar Shemesh via Digitalmars-d
>
> wrote:
> > What will the following code print? Do not use the compiler:
> >
> > import std.stdio;
> >
> > struct A {
> >
> >   int a = 1;
> >
> >   void initialize() {
> >
> >       a = a.init;
> >
> >   }
> >
> > }
> >
> > void main() {
> >
> >   A a;
> >   a.initialize();
> >
> >   writeln(a.a);
> >
> > }
> >
> > I find this behavior unexpected.
>
> It does exactly what I'd expect it to do, though honestly, it's the sort of thing I wish weren't legal, just like I wish that it weren't legal to call a static member function via a member. Maybe there are cases where it's useful, but it just seems wrong.

via in instance, I mean. IMHO, it should be required to do Type.staticMember rather than var.staticMember. The fact that it's allowed is just messy and is one of the things that we inherited from C++ that we shouldn't have. This case falls in the same camp, except that it's a new mistake, since C++ doesn't have init values.

- Jonathan M Davis

On Sun, Jan 28, 2018 at 12:04:42AM -0700, Jonathan M Davis via Digitalmars-d wrote:
> On Saturday, January 27, 2018 23:44:40 Jonathan M Davis via Digitalmars-d wrote:
[...]
> > It does exactly what I'd expect it to do, though honestly, it's the sort of thing I wish weren't legal, just like I wish that it weren't legal to call a static member function via a member. Maybe there are cases where it's useful, but it just seems wrong.
> 
> via in instance, I mean. IMHO, it should be required to do Type.staticMember rather than var.staticMember. The fact that it's allowed is just messy and is one of the things that we inherited from C++ that we shouldn't have. This case falls in the same camp, except that it's a new mistake, since C++ doesn't have init values.
[...]

Are you sure this came from C++? I'm pretty sure instance.staticMember (or instance->staticMember) is not allowed in C++, you have to write Class::staticMember. I distinctly remember, having gotten used to the distinction in C++, being a little surprised that D was lax in this area. In fact, I remember running into problems with my early D code where I relied on this distinction, only to quickly find myself drowning in overload conflicts / ambiguity errors when I tried invoking the methods.


T

-- 
Making non-nullable pointers is just plugging one hole in a cheese grater. -- Walter Bright

On Saturday, January 27, 2018 23:40:16 H. S. Teoh via Digitalmars-d wrote:
> On Sun, Jan 28, 2018 at 12:04:42AM -0700, Jonathan M Davis via
Digitalmars-d wrote:
> > On Saturday, January 27, 2018 23:44:40 Jonathan M Davis via Digitalmars-d
>
> > wrote:
> [...]
>
> > > It does exactly what I'd expect it to do, though honestly, it's the sort of thing I wish weren't legal, just like I wish that it weren't legal to call a static member function via a member. Maybe there are cases where it's useful, but it just seems wrong.
> >
> > via in instance, I mean. IMHO, it should be required to do Type.staticMember rather than var.staticMember. The fact that it's allowed is just messy and is one of the things that we inherited from C++ that we shouldn't have. This case falls in the same camp, except that it's a new mistake, since C++ doesn't have init values.
>
> [...]
>
> Are you sure this came from C++? I'm pretty sure instance.staticMember (or instance->staticMember) is not allowed in C++, you have to write Class::staticMember. I distinctly remember, having gotten used to the distinction in C++, being a little surprised that D was lax in this area. In fact, I remember running into problems with my early D code where I relied on this distinction, only to quickly find myself drowning in overload conflicts / ambiguity errors when I tried invoking the methods.

I'm quite sure, but that doesn't mean that I'm right. Checking... Yep. It works in C++. This code compiles just fine on my FreeBSD system with both g++ and clang++:

class A
{
public:
    static bool foo() { return false; }
};

int main()
{
    A a;
    bool result = a.foo();
    return 0;
}

As to _why_ it works, I don't know - it seems like a bad idea to me - but it does.

- Jonathan M Davis

On 1/28/2018 12:05 AM, Jonathan M Davis wrote:
> As to _why_ it works, I don't know - it seems like a bad idea to me - but it
> does.

It's so your code needn't care whether it is a static member or not, just the implementer of the class needs to care.