You should rethink implementing multiple alias this. D is increasingly becoming a poorly typed language.

"alias this" is basically static prototype-based programming.

http://en.wikipedia.org/wiki/Prototype-based_programming

Self had multiple inheritance based on prototypes and removed it because it was not much used and lead to problems when figuring out which methods were called.

On Tuesday, 28 October 2014 at 22:55:24 UTC, IgorStepanov wrote:
> You may see isFloatingPoint declaration in traits.d:
> enum bool isFloatingPoint(T) = is(FloatingPointTypeOf!T) && !isAggregateType!T;
>
> This template explicitly says that T shouldn't be an aggregate type. Thus
> std.math.isNaN(X)(X x) if (isFloatingPoint!X)
> shouldn't accept a struct.

Although alias this is supposed to denote subtyping, here is a violation of the Liskov Substitution Principle; although S is a subtype of float, there are some cases where it's invalid to substitute an S for a float. This seems like a problem with alias this to me. As S is aliased to float, typeof(s.val) should be passed to isFloatingPoint if passing S fails.

On Tuesday, 28 October 2014 at 23:12:21 UTC, Meta wrote:
> On Tuesday, 28 October 2014 at 22:55:24 UTC, IgorStepanov wrote:
>> You may see isFloatingPoint declaration in traits.d:
>> enum bool isFloatingPoint(T) = is(FloatingPointTypeOf!T) && !isAggregateType!T;
>>
>> This template explicitly says that T shouldn't be an aggregate type. Thus
>> std.math.isNaN(X)(X x) if (isFloatingPoint!X)
>> shouldn't accept a struct.
>
> Although alias this is supposed to denote subtyping, here is a violation of the Liskov Substitution Principle; although S is a subtype of float, there are some cases where it's invalid to substitute an S for a float. This seems like a problem with alias this to me. As S is aliased to float, typeof(s.val) should be passed to isFloatingPoint if passing S fails.

Your issue is not relevant with alias this implementation.
isFloatingPoint is a library implemented trait, which uses compile-time reflections to for verifying the truth of the approval "T is floating point type".
If you think that isFloatingPoint implemented incorrectly, you may start corresponding discussion.
Otherwice, if you think that std.math.isNaN should accept user types which may be converted to floating point type, you may discuss that.
If you want simply solve you problem you may define own
auto isNaN(T)(S!(T) arg)
{
    return isNaN(cast(T)arg);
}

On Tuesday, 28 October 2014 at 22:58:53 UTC, Ola Fosheim Grøstad wrote:
> You should rethink implementing multiple alias this. D is increasingly becoming a poorly typed language.
>
> "alias this" is basically static prototype-based programming.
>
> http://en.wikipedia.org/wiki/Prototype-based_programming
>
> Self had multiple inheritance based on prototypes and removed it because it was not much used and lead to problems when figuring out which methods were called.

No.

D is as poorly typed as one wants is to be and multiple alias this is a necessary tool to achieve strong static typing without sacrificing expressiveness.

On Friday, 10 October 2014 at 17:09:08 UTC, IgorStepanov wrote:
> I've created DIP for my pull request.
> DIP: http://wiki.dlang.org/DIP66
> PR: https://github.com/D-Programming-Language/dmd/pull/3998
>
> Please, comment it.

Well, nearly 3 years later and nothing!

On Friday, 10 October 2014 at 17:09:08 UTC, IgorStepanov wrote:
> I've created DIP for my pull request.
> DIP: http://wiki.dlang.org/DIP66
> PR: https://github.com/D-Programming-Language/dmd/pull/3998
>
> Please, comment it.

What's the state?

On Wednesday, 20 March 2019 at 21:39:48 UTC, sighoya wrote:
> On Friday, 10 October 2014 at 17:09:08 UTC, IgorStepanov wrote:
>> I've created DIP for my pull request.
>> DIP: http://wiki.dlang.org/DIP66
>> PR: https://github.com/D-Programming-Language/dmd/pull/3998
>>
>> Please, comment it.
>
> What's the state?

https://github.com/dlang/dmd/pull/8378

It's waiting on someone willing to work with reviewers to refactor it and integrate it into the codebase to reviewers' satisfaction.

Mike

On Wednesday, 20 March 2019 at 21:50:55 UTC, Mike Franklin wrote:
> On Wednesday, 20 March 2019 at 21:39:48 UTC, sighoya wrote:
>> On Friday, 10 October 2014 at 17:09:08 UTC, IgorStepanov wrote:
>>> I've created DIP for my pull request.
>>> DIP: http://wiki.dlang.org/DIP66
>>> PR: https://github.com/D-Programming-Language/dmd/pull/3998
>>>
>>> Please, comment it.
>>
>> What's the state?
>
> https://github.com/dlang/dmd/pull/8378
>
> It's waiting on someone willing to work with reviewers to refactor it and integrate it into the codebase to reviewers' satisfaction.
>
> Mike

How can I help if I'm not the one creating the PR?

On Wednesday, 20 March 2019 at 21:58:46 UTC, sighoya wrote:

> How can I help if I'm not the one creating the PR?

It needs someone willing to adopt the PR and work with reviewers to get it across the finish line.  If you've never worked on DMD before, cloning the DMD, druntime, Phobos, etc. and learning how to build the compiler and run the test suite locally is the first step.

Mike

On Wednesday, 20 March 2019 at 22:11:00 UTC, Mike Franklin wrote:
> On Wednesday, 20 March 2019 at 21:58:46 UTC, sighoya wrote:
>
>> How can I help if I'm not the one creating the PR?
>
> It needs someone willing to adopt the PR and work with reviewers to get it across the finish line.  If you've never worked on DMD before, cloning the DMD, druntime, Phobos, etc. and learning how to build the compiler and run the test suite locally is the first step.
>
> Mike

So I can become a reviewer only, but how can I propose changes to be merged into the PR proposer's branch, do I need to clone his branch and to create a pull request in hope he accept my changes?