Thread overview
is it regression?
Feb 28, 2018
drug
Feb 28, 2018
Daniel Kozak
Feb 28, 2018
drug
Feb 28, 2018
bauss
Feb 28, 2018
Daniel Kozak
Feb 28, 2018
Jonathan M Davis
February 28, 2018
https://run.dlang.io/is/HJxtvw

```
import std.stdio, std.typecons, std.math;
void main()
{
    auto foo = nullable(2.0);
    auto bar = nullable(2.0);

    assert (foo.approxEqual(bar));
}
```
Comiling gives the following:
Up to      2.067.1: Failure with output:
-----
onlineapp.d(4): Error: undefined identifier nullable, did you mean struct Nullable(T)?
onlineapp.d(5): Error: undefined identifier nullable, did you mean struct Nullable(T)?
-----

2.068.2 to 2.072.2: Failure with output:
-----
onlineapp.d(4): Error: undefined identifier 'nullable', did you mean struct 'Nullable(T)'?
onlineapp.d(5): Error: undefined identifier 'nullable', did you mean struct 'Nullable(T)'?
-----

2.073.2 to 2.077.1: Success and no output
Since      2.078.1: Failure with output:
-----
/path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/math.d(7575): Error: template std.math.approxEqual cannot deduce function from argument types !()(Nullable!double, Nullable!double, double, double), candidates are:
/path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/math.d(7499):      std.math.approxEqual(T, U, V)(T lhs, U rhs, V maxRelDiff, V maxAbsDiff = 1e-05) if ((isNumeric!T || isInputRange!T && isNumeric!(ElementType!T)) && (isNumeric!U || isInputRange!U && isNumeric!(ElementType!U)) && isNumeric!V)
/path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/math.d(7573):      std.math.approxEqual(T, U)(T lhs, U rhs)
onlineapp.d(7): Error: template instance std.math.approxEqual!(Nullable!double, Nullable!double) error instantiating
-----
tldr - std.math.approxEqual stops deduced its args type when Nullable is used.
February 28, 2018
Yes it is a regression, please fill a bug report

On Wed, Feb 28, 2018 at 2:16 PM, drug via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote:

> https://run.dlang.io/is/HJxtvw
>
> ```
> import std.stdio, std.typecons, std.math;
> void main()
> {
>     auto foo = nullable(2.0);
>     auto bar = nullable(2.0);
>
>     assert (foo.approxEqual(bar));
> }
> ```
> Comiling gives the following:
> Up to      2.067.1: Failure with output:
> -----
> onlineapp.d(4): Error: undefined identifier nullable, did you mean struct
> Nullable(T)?
> onlineapp.d(5): Error: undefined identifier nullable, did you mean struct
> Nullable(T)?
> -----
>
> 2.068.2 to 2.072.2: Failure with output:
> -----
> onlineapp.d(4): Error: undefined identifier 'nullable', did you mean
> struct 'Nullable(T)'?
> onlineapp.d(5): Error: undefined identifier 'nullable', did you mean
> struct 'Nullable(T)'?
> -----
>
> 2.073.2 to 2.077.1: Success and no output
> Since      2.078.1: Failure with output:
> -----
> /path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/math.d(7575):
> Error: template std.math.approxEqual cannot deduce function from argument
> types !()(Nullable!double, Nullable!double, double, double), candidates are:
> /path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/math.d(7499):
>   std.math.approxEqual(T, U, V)(T lhs, U rhs, V maxRelDiff, V maxAbsDiff =
> 1e-05) if ((isNumeric!T || isInputRange!T && isNumeric!(ElementType!T)) &&
> (isNumeric!U || isInputRange!U && isNumeric!(ElementType!U)) && isNumeric!V)
> /path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/math.d(7573):
>   std.math.approxEqual(T, U)(T lhs, U rhs)
> onlineapp.d(7): Error: template instance std.math.approxEqual!(Nullable!double,
> Nullable!double) error instantiating
> -----
> tldr - std.math.approxEqual stops deduced its args type when Nullable is used.
>


February 28, 2018
done https://issues.dlang.org/show_bug.cgi?id=18539
February 28, 2018
On Wednesday, 28 February 2018 at 13:38:56 UTC, drug wrote:
> done https://issues.dlang.org/show_bug.cgi?id=18539

I would argue that isn't a regression and that you __should__ use the .get and that it's not a workaround, because nullable's shouldn't be treated like that type they encapsulate.

std.math members such as approxEqual shouldn't have to take nullable into account.
February 28, 2018
I would say it is a still regression, but I agree with you, that it should not work on the first place.

On Wed, Feb 28, 2018 at 3:28 PM, bauss via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote:

> On Wednesday, 28 February 2018 at 13:38:56 UTC, drug wrote:
>
>> done https://issues.dlang.org/show_bug.cgi?id=18539
>>
>
> I would argue that isn't a regression and that you __should__ use the .get and that it's not a workaround, because nullable's shouldn't be treated like that type they encapsulate.
>
> std.math members such as approxEqual shouldn't have to take nullable into account.
>


February 28, 2018
On Wednesday, February 28, 2018 14:28:47 bauss via Digitalmars-d-learn wrote:
> On Wednesday, 28 February 2018 at 13:38:56 UTC, drug wrote:
> > done https://issues.dlang.org/show_bug.cgi?id=18539
>
> I would argue that isn't a regression and that you __should__ use the .get and that it's not a workaround, because nullable's shouldn't be treated like that type they encapsulate.
>
> std.math members such as approxEqual shouldn't have to take nullable into account.

approxEqual shouldn't have to take Nullable into account. The fact that (for better or worse), Nullable's get is alias this-ed should take care of it. Given that alias this, it should just work without approxEqual doing anything. And if get were actually deprecated and removed, then approxEqual still wouldn't take Nullable into account, since at that point, get would be called explicitly.

- Jonathan M Davis