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
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
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
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
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
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
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
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
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
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
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
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
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
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/31/2018 4:19 PM, Amorphorious wrote:
 [...]
Don't berate other forum members.
Jan 31
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
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
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
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
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
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
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
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