digitalmars.D.learn - is it regression?
- drug (44/44) Feb 28 2018 https://run.dlang.io/is/HJxtvw
- Daniel Kozak (3/45) Feb 28 2018 Yes it is a regression, please fill a bug report
- drug (1/1) Feb 28 2018 done https://issues.dlang.org/show_bug.cgi?id=18539
- bauss (6/7) Feb 28 2018 I would argue that isn't a regression and that you __should__ use
- Daniel Kozak (4/12) Feb 28 2018 I would say it is a still regression, but I agree with you, that it shou...
- Jonathan M Davis (9/16) Feb 28 2018 approxEqual shouldn't have to take Nullable into account. The fact that ...
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.
Feb 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.
Feb 28 2018
On Wednesday, 28 February 2018 at 13:38:56 UTC, drug wrote:done https://issues.dlang.org/show_bug.cgi?id=18539I 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.
Feb 28 2018
Daniel Kozak <kozzi11 gmail.com> 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=18539I 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.
Feb 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: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 Davisdone https://issues.dlang.org/show_bug.cgi?id=18539I 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.
Feb 28 2018