www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The daily D riddle

reply Shachar Shemesh <shachar weka.io> writes:
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.
Jan 27 2018
next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
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.
Jan 27 2018
parent reply Shachar Shemesh <shachar weka.io> writes:
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.
Jan 27 2018
parent Jorge Lima <jmalima69 gmail.com> writes:
On Sunday, 28 January 2018 at 06:44:06 UTC, Shachar Shemesh wrote:

 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.


I also run the test and it worked as I expected. It seems pretty 
straingtforward logic. I wonder if I didn't get your question 
right. What result were you expecting and why?
Jan 31 2018
prev sibling next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Jan 27 2018
parent reply Timothee Cour <thelastmammoth gmail.com> writes:
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
Jan 27 2018
next sibling parent reply Seb <seb wilzba.ch> writes:
On Sunday, 28 January 2018 at 06:44:28 UTC, Timothee Cour wrote:

 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


Yes, good idea!
Jan 28 2018
parent reply Daniel Kozak <kozzi11 gmail.com> writes:
https://run.dlang.io/is/gVL0g7

On Sun, Jan 28, 2018 at 12:23 PM, Seb via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Sunday, 28 January 2018 at 06:44:28 UTC, Timothee Cour wrote:


 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


 Yes, good idea!
Jan 28 2018
parent Seb <seb wilzba.ch> writes:
On Sunday, 28 January 2018 at 11:41:44 UTC, Daniel Kozak wrote:

 https://run.dlang.io/is/gVL0g7

 On Sun, Jan 28, 2018 at 12:23 PM, Seb via Digitalmars-d < 
 digitalmars-d puremagic.com> wrote:


 On Sunday, 28 January 2018 at 06:44:28 UTC, Timothee Cour 
 wrote:


 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


 Yes, good idea!





But `typeof(a).init` would have the same behavior here: 
https://run.dlang.io/is/jvG2hW
Jan 28 2018
prev sibling parent reply Nick Treleaven <nick geany.org> writes:
On Sunday, 28 January 2018 at 06:44:28 UTC, Timothee Cour wrote:

 likewise the following compiles, but IMO should not:
 class A{ void fun(this a){}}
 (instead we should have typeof(this)


Yes, it's also confusing reading it, I thought it was template 
this for a second. It even works if fun is static! This is ironic 
as template this doesn't work outside of methods, even though it 
should:
https://issues.dlang.org/show_bug.cgi?id=17713

In fact, template this syntax is backward:

void fun(this T)(){} // current
void fun(T this)(){} // could work?

The latter actually has the type and variable in the correct 
position. (Not that I expect it will change now).
Feb 01 2018
parent bauss <jj_1337 live.dk> writes:
On Thursday, 1 February 2018 at 13:12:21 UTC, Nick Treleaven 
wrote:

 On Sunday, 28 January 2018 at 06:44:28 UTC, Timothee Cour wrote:

 likewise the following compiles, but IMO should not:
 class A{ void fun(this a){}}
 (instead we should have typeof(this)


 Yes, it's also confusing reading it, I thought it was template 
 this for a second. It even works if fun is static! This is 
 ironic as template this doesn't work outside of methods, even 
 though it should:
 https://issues.dlang.org/show_bug.cgi?id=17713

 In fact, template this syntax is backward:

 void fun(this T)(){} // current
 void fun(T this)(){} // could work?

 The latter actually has the type and variable in the correct 
 position. (Not that I expect it will change now).


I like the current way, because it doesn't look like a variable, 
because it really isn't a variable. It's really just telling the 
compiler that the type of the this pointer is that of T.
Feb 05 2018
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Jan 27 2018
parent reply Amorphorious <Amorphorious gmail.com> writes:
On Sunday, 28 January 2018 at 06:44:40 UTC, Jonathan M Davis 
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.

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

 - Jonathan M Davis


One day you will hopefully learn that you are not the god of 
logic and just because you think something is right or wrong 
doesn't mean it is so.  What happens with people like you is that 
they end up causing more problems down the road because they were 
wrong and too ignorant to understand it. It's not your fault... 
blame it on evolution if you want, but what determines right and 
wrong  should be decided by mathematical proof, not gut feelings.
Jan 31 2018
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/31/2018 4:19 PM, Amorphorious wrote:

 [...]


Don't berate other forum members.
Jan 31 2018
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Jan 27 2018
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Jan 27 2018
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Jan 28 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 28 2018
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Jan 28, 2018 at 12:27:52AM -0800, Walter Bright via Digitalmars-d wrote:

 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.


Is there a practical use case for which this is actually useful?

Most of the time, if I'm calling a static method, there's a specific
reason why it's a static method rather than a normal method, e.g., it
could be a factory method for constructing an instance of the class.  It
wouldn't make any sense for code calling that method to need an object
to invoke it with.  Conversely, if I'm calling a non-static method, the
expectation is that it's doing something to a specific instance of the
class, not something global to all instances.  While theoretically it
*could* be useful to be agnostic about whether a method is static or
non-static, I can't think of any real-world use case for it.  Do you
have one in mind?


T

-- 
Your inconsistency is the only consistent thing about you! -- KD
Jan 28 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/28/2018 12:36 AM, H. S. Teoh wrote:

 Is there a practical use case for which this is actually useful?


Generic code, where a member function doesn't need the instance to perform its
task.
Jan 28 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, January 28, 2018 01:52:58 Walter Bright via Digitalmars-d wrote:

 On 1/28/2018 12:36 AM, H. S. Teoh wrote:

 Is there a practical use case for which this is actually useful?


 Generic code, where a member function doesn't need the instance to perform
 its task.


Maybe there's a situation where that would make sense, but personally, I
would consider static to be a core part of a function's API, and I would
expect it to be clear as to whether it needed access to an instance by its
very nature, in which case, it wouldn't make sense to have the same function
static in one type and not another and then be used generically.

- Jonathan M Davis
Jan 28 2018
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 28.01.2018 15:59, Jonathan M Davis wrote:

 On Sunday, January 28, 2018 01:52:58 Walter Bright via Digitalmars-d wrote:

 On 1/28/2018 12:36 AM, H. S. Teoh wrote:

 Is there a practical use case for which this is actually useful?


 Generic code, where a member function doesn't need the instance to perform
 its task.


 
 Maybe there's a situation where that would make sense, but personally, I
 would consider static to be a core part of a function's API, and I would
 expect it to be clear as to whether it needed access to an instance by its
 very nature, in which case, it wouldn't make sense to have the same function
 static in one type and not another and then be used generically.
 
 - Jonathan M Davis
 


Check out Andrei's allocators.
Jan 28 2018