Re: The daily D riddle - this parameter
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.
Re: The daily D riddle - this parameter
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).
Re: The daily D riddle
On 1/31/2018 4:19 PM, Amorphorious wrote: [...] Don't berate other forum members.
Re: The daily D riddle
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.
Re: The daily D riddle
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?
Re: The daily D riddle
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.
Re: The daily D riddle
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
Re: The daily D riddle
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
Re: The daily D riddle
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!
>
Re: The daily D riddle
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!
Re: The daily D riddle
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.
Re: The daily D riddle
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
Re: The daily D riddle
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.
Re: The daily D riddle
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
Re: The daily D riddle
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
Re: The daily D riddle
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
Re: The daily D riddle
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
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
Re: The daily D riddle
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
Re: The daily D riddle
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.
Re: The daily D riddle
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
Re: The daily D riddle
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.
The daily D riddle
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.
