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

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.

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!

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!
>

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

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

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.

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?

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.

On 1/31/2018 4:19 PM, Amorphorious wrote:
> [...]

Don't berate other forum members.