FAQ
Hi, I have the following code fragment:

package main


import(

     "fmt"

     "strconv"

)


func convert(val interface{}, text string) {

     switch t := val.(type) {

     case *float32:

         v, err := strconv.ParseFloat(text, 32)

         if err == nil {

             *t = float32(v)

         }


     default:

         panic("Unknown type")

     }

}


func main(){

     var f float64

     convert(&f,"345.344")

     fmt.Println(f)

}


I want if I supply wrong type to `convert`, compiler to tell me, instead waiting for runtime panic.

Is there any way?


--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Martin Angers at May 9, 2013 at 12:16 pm
    Well, if you only have to support floats, `convert(text string) float64`.
    But the gain over calling strconv.ParseFloat directly is minimal. If you
    want to support multiple types in convert, then you can't. Go doesn't
    support generics (yet?), so you have to rely on runtime type assertions,
    like you did, and like the stdlib does in places where it has the same
    needs as you (encoding/binary comes to mind).

    Le jeudi 9 mai 2013 08:10:57 UTC-4, [email protected] a écrit :
    Hi, I have the following code fragment:

    package main


    import(

    "fmt"

    "strconv"

    )


    func convert(val interface{}, text string) {

    switch t := val.(type) {

    case *float32:

    v, err := strconv.ParseFloat(text, 32)

    if err == nil {

    *t = float32(v)

    }


    default:

    panic("Unknown type")

    }

    }


    func main(){

    var f float64

    convert(&f,"345.344")

    fmt.Println(f)

    }


    I want if I supply wrong type to `convert`, compiler to tell me, instead waiting for runtime panic.

    Is there any way?

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitry Vyukov at May 9, 2013 at 12:25 pm
    Another option is
    func convertFloat
    func convertInt
    ...
    On Thu, May 9, 2013 at 4:16 PM, Martin Angers wrote:
    Well, if you only have to support floats, `convert(text string) float64`.
    But the gain over calling strconv.ParseFloat directly is minimal. If you
    want to support multiple types in convert, then you can't. Go doesn't
    support generics (yet?), so you have to rely on runtime type assertions,
    like you did, and like the stdlib does in places where it has the same needs
    as you (encoding/binary comes to mind).

    Le jeudi 9 mai 2013 08:10:57 UTC-4, [email protected] a écrit :
    Hi, I have the following code fragment:

    package main


    import(

    "fmt"

    "strconv"

    )


    func convert(val interface{}, text string) {

    switch t := val.(type) {

    case *float32:

    v, err := strconv.ParseFloat(text, 32)

    if err == nil {

    *t = float32(v)

    }


    default:

    panic("Unknown type")

    }

    }


    func main(){

    var f float64

    convert(&f,"345.344")

    fmt.Println(f)

    }


    I want if I supply wrong type to `convert`, compiler to tell me, instead
    waiting for runtime panic.

    Is there any way?
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Drago Ivanov at May 9, 2013 at 1:10 pm
    Yes, there will be other types. I used float32 only for simplicity.
    Runtime is not good. It takes away possibilities to catch errors early.
    Does anyone proposed it to Google (I guess at expense of another keyword)?

    09 май 2013, четвъртък, 15:10:57 UTC+3, [email protected] написа:
    Hi, I have the following code fragment:

    package main


    import(

    "fmt"

    "strconv"

    )


    func convert(val interface{}, text string) {

    switch t := val.(type) {

    case *float32:

    v, err := strconv.ParseFloat(text, 32)

    if err == nil {

    *t = float32(v)

    }


    default:

    panic("Unknown type")

    }

    }


    func main(){

    var f float64

    convert(&f,"345.344")

    fmt.Println(f)

    }


    I want if I supply wrong type to `convert`, compiler to tell me, instead waiting for runtime panic.

    Is there any way?

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Martin Angers at May 9, 2013 at 1:19 pm
    If your real-case types are custom types, you can always make them
    implement an interface (not the empty one), and have convert() expect this
    interface. Then the compiler will make sure only types that satisfy this
    interface can be passed to convert. But if it is for basic types such as
    floats and ints, this won't work (unless you define a type MyFloat float64,
    for example, and make MyFloat satisfy the interface, but then you will have
    to cast normal floats to MyFloat).


    Le jeudi 9 mai 2013 09:10:42 UTC-4, [email protected] a écrit :
    Yes, there will be other types. I used float32 only for simplicity.
    Runtime is not good. It takes away possibilities to catch errors early.
    Does anyone proposed it to Google (I guess at expense of another keyword)?

    09 май 2013, четвъртък, 15:10:57 UTC+3, [email protected] написа:
    Hi, I have the following code fragment:

    package main


    import(

    "fmt"

    "strconv"

    )


    func convert(val interface{}, text string) {

    switch t := val.(type) {

    case *float32:

    v, err := strconv.ParseFloat(text, 32)

    if err == nil {

    *t = float32(v)

    }


    default:

    panic("Unknown type")

    }

    }


    func main(){

    var f float64

    convert(&f,"345.344")

    fmt.Println(f)

    }


    I want if I supply wrong type to `convert`, compiler to tell me, instead waiting for runtime panic.

    Is there any way?

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jan Mercl at May 9, 2013 at 1:14 pm

    On Thu, May 9, 2013 at 2:10 PM, wrote:
    I want if I supply wrong type to `convert`, compiler to tell me, instead
    waiting for runtime panic.
    If you subvert the type system using 'interface{}' typed arguments
    then do not ask for them being statically type checked. This is not an
    insult, it's a simple fact about how the type system works.

    'interface{}' typed entities have static type 'interface{}' and _that_
    type _is_ statically checked by the compiler. The _dynamic_ type of
    the 'interface{}' payload cannot be statically checked: dynamic vs
    static, pick one. As in: you cannot eat the cake and have it.

    -j

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Drago Ivanov at May 9, 2013 at 1:20 pm
    Yes, you are right. Generics is what I need.
    I hope they add some form of them in the future. They are really handy.
    Thank you.

    09 май 2013, четвъртък, 16:14:03 UTC+3, Jan Mercl написа:
    On Thu, May 9, 2013 at 2:10 PM, <[email protected] <javascript:>>
    wrote:
    I want if I supply wrong type to `convert`, compiler to tell me, instead
    waiting for runtime panic.
    If you subvert the type system using 'interface{}' typed arguments
    then do not ask for them being statically type checked. This is not an
    insult, it's a simple fact about how the type system works.

    'interface{}' typed entities have static type 'interface{}' and _that_
    type _is_ statically checked by the compiler. The _dynamic_ type of
    the 'interface{}' payload cannot be statically checked: dynamic vs
    static, pick one. As in: you cannot eat the cake and have it.

    -j
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rémy Oudompheng at May 9, 2013 at 2:48 pm
    You want to handle a finite number of types and not sharing code
    between the handling of the types.
    What's the relation with generics?

    Rémy.


    2013/5/9, [email protected] <[email protected]>:
    Yes, you are right. Generics is what I need.
    I hope they add some form of them in the future. They are really handy.
    Thank you.

    09 май 2013, четвъртък, 16:14:03 UTC+3, Jan Mercl написа:
    On Thu, May 9, 2013 at 2:10 PM, <[email protected] <javascript:>>
    wrote:
    I want if I supply wrong type to `convert`, compiler to tell me, instead

    waiting for runtime panic.
    If you subvert the type system using 'interface{}' typed arguments
    then do not ask for them being statically type checked. This is not an
    insult, it's a simple fact about how the type system works.

    'interface{}' typed entities have static type 'interface{}' and _that_
    type _is_ statically checked by the compiler. The _dynamic_ type of
    the 'interface{}' payload cannot be statically checked: dynamic vs
    static, pick one. As in: you cannot eat the cake and have it.

    -j
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Drago Ivanov at May 9, 2013 at 3:08 pm
    I need compile time error, for not handled types.

    09 май 2013, четвъртък, 17:48:48 UTC+3, Rémy Oudompheng написа:
    You want to handle a finite number of types and not sharing code
    between the handling of the types.
    What's the relation with generics?

    Rémy.


    2013/5/9, [email protected] <javascript:> <[email protected]<javascript:>>:
    Yes, you are right. Generics is what I need.
    I hope they add some form of them in the future. They are really handy.
    Thank you.

    09 май 2013, четвъртък, 16:14:03 UTC+3, Jan Mercl написа:
    On Thu, May 9, 2013 at 2:10 PM, <[email protected] <javascript:>>
    wrote:
    I want if I supply wrong type to `convert`, compiler to tell me,
    instead
    waiting for runtime panic.
    If you subvert the type system using 'interface{}' typed arguments
    then do not ask for them being statically type checked. This is not an
    insult, it's a simple fact about how the type system works.

    'interface{}' typed entities have static type 'interface{}' and _that_
    type _is_ statically checked by the compiler. The _dynamic_ type of
    the 'interface{}' payload cannot be statically checked: dynamic vs
    static, pick one. As in: you cannot eat the cake and have it.

    -j
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to [email protected] <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rémy Oudompheng at May 9, 2013 at 3:33 pm
    But why do you want to use the same function for different types?

    2013/5/9, [email protected] <[email protected]>:
    I need compile time error, for not handled types.

    09 май 2013, четвъртък, 17:48:48 UTC+3, Rémy Oudompheng написа:
    You want to handle a finite number of types and not sharing code
    between the handling of the types.
    What's the relation with generics?

    Rémy.


    2013/5/9, [email protected] <javascript:>
    <[email protected]<javascript:>>:
    Yes, you are right. Generics is what I need.
    I hope they add some form of them in the future. They are really handy.

    Thank you.

    09 май 2013, четвъртък, 16:14:03 UTC+3, Jan Mercl написа:
    On Thu, May 9, 2013 at 2:10 PM, <[email protected] <javascript:>>
    wrote:
    I want if I supply wrong type to `convert`, compiler to tell me,
    instead
    waiting for runtime panic.
    If you subvert the type system using 'interface{}' typed arguments
    then do not ask for them being statically type checked. This is not an

    insult, it's a simple fact about how the type system works.

    'interface{}' typed entities have static type 'interface{}' and _that_

    type _is_ statically checked by the compiler. The _dynamic_ type of
    the 'interface{}' payload cannot be statically checked: dynamic vs
    static, pick one. As in: you cannot eat the cake and have it.

    -j
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to [email protected] <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Drago Ivanov at May 9, 2013 at 3:38 pm
    Yes, maybe I wasn't clear on that. I just want more clean implementation. I
    just want convert([type],string), not caring actually what [type] is.
    It can be done with distinct functions, but I wanted to try with more
    generic one first.

    09 май 2013, четвъртък, 18:33:03 UTC+3, Rémy Oudompheng написа:
    But why do you want to use the same function for different types?

    2013/5/9, [email protected] <javascript:> <[email protected]<javascript:>>:
    I need compile time error, for not handled types.

    09 май 2013, четвъртък, 17:48:48 UTC+3, Rémy Oudompheng написа:
    You want to handle a finite number of types and not sharing code
    between the handling of the types.
    What's the relation with generics?

    Rémy.


    2013/5/9, [email protected] <javascript:>
    <[email protected]<javascript:>>:
    Yes, you are right. Generics is what I need.
    I hope they add some form of them in the future. They are really
    handy.
    Thank you.

    09 май 2013, четвъртък, 16:14:03 UTC+3, Jan Mercl написа:
    On Thu, May 9, 2013 at 2:10 PM, <[email protected]<javascript:>>
    wrote:
    I want if I supply wrong type to `convert`, compiler to tell me,
    instead
    waiting for runtime panic.
    If you subvert the type system using 'interface{}' typed arguments
    then do not ask for them being statically type checked. This is not
    an
    insult, it's a simple fact about how the type system works.

    'interface{}' typed entities have static type 'interface{}' and
    _that_
    type _is_ statically checked by the compiler. The _dynamic_ type of
    the 'interface{}' payload cannot be statically checked: dynamic vs
    static, pick one. As in: you cannot eat the cake and have it.

    -j
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it,
    send
    an
    email to [email protected] <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to [email protected] <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rémy Oudompheng at May 9, 2013 at 3:59 pm
    It is not more clean nor is it more generic. Go has ruled out function
    overloading precisely because it makes things more confusing.

    The discussion is not about genericness.

    Rémy.


    2013/5/9, [email protected] <[email protected]>:
    Yes, maybe I wasn't clear on that. I just want more clean implementation. I

    just want convert([type],string), not caring actually what [type] is.
    It can be done with distinct functions, but I wanted to try with more
    generic one first.

    09 май 2013, четвъртък, 18:33:03 UTC+3, Rémy Oudompheng написа:
    But why do you want to use the same function for different types?

    2013/5/9, [email protected] <javascript:>
    <[email protected]<javascript:>>:
    I need compile time error, for not handled types.

    09 май 2013, четвъртък, 17:48:48 UTC+3, Rémy Oudompheng написа:
    You want to handle a finite number of types and not sharing code
    between the handling of the types.
    What's the relation with generics?

    Rémy.


    2013/5/9, [email protected] <javascript:>
    <[email protected]<javascript:>>:
    Yes, you are right. Generics is what I need.
    I hope they add some form of them in the future. They are really
    handy.
    Thank you.

    09 май 2013, четвъртък, 16:14:03 UTC+3, Jan Mercl написа:
    On Thu, May 9, 2013 at 2:10 PM, <[email protected]<javascript:>>

    wrote:
    I want if I supply wrong type to `convert`, compiler to tell me,
    instead
    waiting for runtime panic.
    If you subvert the type system using 'interface{}' typed arguments
    then do not ask for them being statically type checked. This is not
    an
    insult, it's a simple fact about how the type system works.

    'interface{}' typed entities have static type 'interface{}' and
    _that_
    type _is_ statically checked by the compiler. The _dynamic_ type of

    the 'interface{}' payload cannot be statically checked: dynamic vs
    static, pick one. As in: you cannot eat the cake and have it.

    -j
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it,
    send
    an
    email to [email protected] <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to [email protected] <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Drago Ivanov at May 9, 2013 at 3:45 pm
    Here is what i come up:

    package main


    import(

         "fmt"

         "strconv"

    )


    type Float32 float32

    type Float64 float64


    type TypeConverter interface {

         typeConvert(text string)

    }


    func (f *Float32) typeConvert(text string) {

         v, err := strconv.ParseFloat(text, 32)

         if err == nil {

             *f = Float32(v)

         }

    }


    func convert(val TypeConverter, text string) {

         val.typeConvert(text)

    }


    func main() {

         {

             var f Float32

             convert(&f,"345.344")

             fmt.Println(f)

         }

    }


    Changing Float32 for Float64, gives compile time error:

    ./goplay.go:29: cannot use &f (type *Float64) as type TypeConverter in function argument:

      *Float64 does not implement TypeConverter (missing typeConvert method)


    09 май 2013, четвъртък, 15:10:57 UTC+3, [email protected] написа:
    Hi, I have the following code fragment:

    package main


    import(

    "fmt"

    "strconv"

    )


    func convert(val interface{}, text string) {

    switch t := val.(type) {

    case *float32:

    v, err := strconv.ParseFloat(text, 32)

    if err == nil {

    *t = float32(v)

    }


    default:

    panic("Unknown type")

    }

    }


    func main(){

    var f float64

    convert(&f,"345.344")

    fmt.Println(f)

    }


    I want if I supply wrong type to `convert`, compiler to tell me, instead waiting for runtime panic.

    Is there any way?

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Steven Blenkinsop at May 9, 2013 at 8:29 pm
    A few days ago, Sean Russell pointed out that defining unexported methods
    on built-in types wouldn't cause the same problems as defining exported
    methods on them would[1]. Of course, it doesn't seem all that useful to
    define unexported methods on types you don't own, since most of the time a
    function would serve just as well. I find it interesting that 4 days later,
    a use case popped up. This code would work with built-in types if you could
    define unexported methods directly on them (or any other named type that
    isn't declared in your package). Not to say that allowing this would
    necessarily be a good idea, since it might muddle up people's idea of where
    methods can be defined.

    [1] https://groups.google.com/d/msg/golang-nuts/bhpaR1Pwff4/sU9FKDkM5_IJ
    On Thu, May 9, 2013 at 11:45 AM, wrote:

    Here is what i come up:

    package main


    import(

    "fmt"

    "strconv"

    )


    type Float32 float32

    type Float64 float64


    type TypeConverter interface {

    typeConvert(text string)

    }


    func (f *Float32) typeConvert(text string) {

    v, err := strconv.ParseFloat(text, 32)

    if err == nil {

    *f = Float32(v)

    }

    }


    func convert(val TypeConverter, text string) {

    val.typeConvert(text)

    }


    func main() {

    {

    var f Float32

    convert(&f,"345.344")

    fmt.Println(f)

    }

    }


    Changing Float32 for Float64, gives compile time error:

    ./goplay.go:29: cannot use &f (type *Float64) as type TypeConverter in function argument:

    *Float64 does not implement TypeConverter (missing typeConvert method)


    09 май 2013, четвъртък, 15:10:57 UTC+3, [email protected] написа:
    Hi, I have the following code fragment:

    package main


    import(

    "fmt"

    "strconv"

    )


    func convert(val interface{}, text string) {

    switch t := val.(type) {

    case *float32:

    v, err := strconv.ParseFloat(text, 32)

    if err == nil {

    *t = float32(v)

    }


    default:

    panic("Unknown type")

    }

    }


    func main(){

    var f float64

    convert(&f,"345.344")

    fmt.Println(f)

    }


    I want if I supply wrong type to `convert`, compiler to tell me, instead waiting for runtime panic.

    Is there any way?


    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • André Moraes at May 9, 2013 at 11:14 pm

    type Float32 float32
    type Float64 float64

    type TypeConverter interface {

    typeConvert(text string)

    }


    func (f *Float32) typeConvert(text string) {

    v, err := strconv.ParseFloat(text, 32)

    if err == nil {

    *f = Float32(v)

    }

    }
    You just implemented the Unmarshaler idiom.

    http://golang.org/pkg/encoding/json/#Unmarshaler

    Check the http://golang.org/pkg/encoding, you could get some inspiration there

    --
    André Moraes
    http://amoraes.info

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMay 9, '13 at 12:11p
activeMay 9, '13 at 11:14p
posts15
users7
websitegolang.org

People

Translate

site design / logo © 2023 Grokbase