Since the literal 3.0 is a Double so you'd have to catch every floating point type (including CGFloat, I suspect etc.) vs. just trying to cast to a Float (although I guess casting to a Float could have unexpected results also if someone made an extension that allows a type to be cast as a Float).
Dave
···
On Oct 1, 2017, at 2:32 PM, Glenn L. Austin <glenn@austinsoft.com> wrote:
On Oct 1, 2017, at 8:56 AM, Dave Reed via swift-users <swift-users@swift.org> wrote:
On Sep 21, 2017, at 3:58 PM, V T via swift-users <swift-users@swift.org> wrote:
Hi there!
Is there a best way to check if a given type conforms to numeric protocol (Integer or FP) at runtime?
func checkNumeric<T>(_ value: T) {
/* return true if vaiue is Integer or FP */
/* this will not compile: */
if value is Numeric {
}
}
Best regards!
VT
I think the way to do it is to try casting as the type, but you can't use "as? Numeric" as you get:
error: protocol 'Numeric' can only be used as a generic constraint because it has Self or associated type requirements
but you could check for each specific numeric type such as:
Since the literal 3.0 is a Double so you'd have to catch every floating point type (including CGFloat, I suspect etc.) vs. just trying to cast to a Float (although I guess casting to a Float could have unexpected results also if someone made an extension that allows a type to be cast as a Float).
I don't recall whether or not swift will pick the right version of the
function here, or whether this can even compile (mac isnt open at the
moment), but if you can overload functions in this way then it might be
much nicer than checking for lots of concrete types.
···
On 10/1/2017 6:27 PM, V T via swift-users wrote:
On 1. Oct 2017, at 22:43, davelist@mac.com <mailto:davelist@mac.com> >> wrote:
On Oct 1, 2017, at 2:32 PM, Glenn L. Austin <glenn@austinsoft.com >>> <mailto:glenn@austinsoft.com>> wrote:
On Oct 1, 2017, at 8:56 AM, Dave Reed via swift-users >>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
On Sep 21, 2017, at 3:58 PM, V T via swift-users >>>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
Hi there!
Is there a best way to check if a given type conforms to numeric
protocol (Integer or FP) at runtime?
func checkNumeric<T>(_ value: T) {
/* return true if vaiue is Integer or FP */
/* this will not compile: */
if value is Numeric {
}
}
Best regards!
VT
I think the way to do it is to try casting as the type, but you
can't use "as? Numeric" as you get:
error: protocol 'Numeric' can only be used as a generic constraint
because it has Self or associated type requirements
but you could check for each specific numeric type such as:
Since the literal 3.0 is a Double so you'd have to catch every
floating point type (including CGFloat, I suspect etc.) vs. just
trying to cast to a Float (although I guess casting to a Float could
have unexpected results also if someone made an extension that allows
a type to be cast as a Float).
I don't recall whether or not swift will pick the right version of the
function here, or whether this can even compile (mac isnt open at the
moment), but if you can overload functions in this way then it might
be much nicer than checking for lots of concrete types.
On 10/1/2017 6:27 PM, V T via swift-users wrote:
On 1. Oct 2017, at 22:43, davelist@mac.com <mailto:davelist@mac.com> >>> wrote:
On Oct 1, 2017, at 2:32 PM, Glenn L. Austin <glenn@austinsoft.com >>>> <mailto:glenn@austinsoft.com>> wrote:
On Oct 1, 2017, at 8:56 AM, Dave Reed via swift-users >>>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
On Sep 21, 2017, at 3:58 PM, V T via swift-users >>>>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
Hi there!
Is there a best way to check if a given type conforms to numeric
protocol (Integer or FP) at runtime?
func checkNumeric<T>(_ value: T) {
/* return true if vaiue is Integer or FP */
/* this will not compile: */
if value is Numeric {
}
}
Best regards!
VT
I think the way to do it is to try casting as the type, but you
can't use "as? Numeric" as you get:
error: protocol 'Numeric' can only be used as a generic constraint
because it has Self or associated type requirements
but you could check for each specific numeric type such as:
Since the literal 3.0 is a Double so you'd have to catch every
floating point type (including CGFloat, I suspect etc.) vs. just
trying to cast to a Float (although I guess casting to a Float could
have unexpected results also if someone made an extension that
allows a type to be cast as a Float).
It’ll compile, but you’ll get the wrong answer if it’s called from another generic function that isn’t similarly overloaded for `T` vs `T: Numeric`. I’m not at my computer right now, but IIRC, this is correct:
I don't recall whether or not swift will pick the right version of the function here, or whether this can even compile (mac isnt open at the moment), but if you can overload functions in this way then it might be much nicer than checking for lots of concrete types.
That was my point... `foo` doesn’t have a `T: Numeric` version, therefore when it calls `isNumeric` the compiler has to call the version that always return false. `bar` is overloaded with both a `T` and a `T: Numeric` version, so there the compiler can call the most appropriate version of `isNumeric`.
- Dave Sweeris
···
On Oct 5, 2017, at 01:49, Alex Blewitt <alblue@apple.com> wrote:
I think one of your 'foo' or 'bar' is missing a <T:Numeric>, as otherwise the functions are identical ...
Alex
On 5 Oct 2017, at 09:23, David Sweeris via swift-users <swift-users@swift.org> wrote:
On Oct 4, 2017, at 18:30, Kevin Lundberg via swift-users <swift-users@swift.org> wrote:
I don't recall whether or not swift will pick the right version of the function here, or whether this can even compile (mac isnt open at the moment), but if you can overload functions in this way then it might be much nicer than checking for lots of concrete types.
It’ll compile, but you’ll get the wrong answer if it’s called from another generic function that isn’t similarly overloaded for `T` vs `T: Numeric`. I’m not at my computer right now, but IIRC, this is correct: