FAQ
I've calculated an interval as a time.Duration. I want to print out a
Duration that is 100 (for example) times as long?

The obvious expression gets a syntax error:
* invalid operation: maxOutstanding * runTime (mismatched types int and
time.Duration)*

Using go 1.1.1

    Thanks,
    Ricky

--
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 golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Minux at Jun 19, 2013 at 1:24 pm

    On Wed, Jun 19, 2013 at 9:22 PM, RickyS wrote:
    I've calculated an interval as a time.Duration. I want to print out a
    Duration that is 100 (for example) times as long?

    The obvious expression gets a syntax error:
    invalid operation: maxOutstanding * runTime (mismatched types int and
    time.Duration)
    just convert the integer to time.Duration:
    time.Duration(maxOutstanding) * runTime

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Chris dollin at Jun 19, 2013 at 1:35 pm

    On 19 June 2013 14:24, minux wrote:
    On Wed, Jun 19, 2013 at 9:22 PM, RickyS wrote:
    I've calculated an interval as a time.Duration. I want to print out a
    Duration that is 100 (for example) times as long?

    The obvious expression gets a syntax error:
    invalid operation: maxOutstanding * runTime (mismatched types int and
    time.Duration)
    just convert the integer to time.Duration:
    time.Duration(maxOutstanding) * runTime<https://groups.google.com/groups/opt_out>

    I'd feel dimensionally suspect multiplying a Duration by a Duration
    and getting a Duration back.

    time.Duration(maxOutstanding * int(runTime)) would make me feel
    dimensionally satisfied at the cost of an extra cast.

    How do others feel about this?

    Chris

    PS "invalid operation" isn't a syntax error, at least in the way I think
    of syntax errors: `maxOutstanding * runTime` is a perfectly
    syntactic expression that happens, by virtue of certain properties
    of the identifiers in it, to be disallowed.

    AgainChris

    --
    Chris "allusive" Dollin

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Jun 19, 2013 at 1:43 pm

    On Wed, Jun 19, 2013 at 9:35 PM, chris dollin wrote:
    On 19 June 2013 14:24, minux wrote:
    On Wed, Jun 19, 2013 at 9:22 PM, RickyS wrote:
    I've calculated an interval as a time.Duration. I want to print out a
    Duration that is 100 (for example) times as long?

    The obvious expression gets a syntax error:
    invalid operation: maxOutstanding * runTime (mismatched types int and
    time.Duration)
    just convert the integer to time.Duration:
    time.Duration(maxOutstanding) * runTime
    I'd feel dimensionally suspect multiplying a Duration by a Duration
    and getting a Duration back.

    time.Duration(maxOutstanding * int(runTime)) would make me feel
    dimensionally satisfied at the cost of an extra cast.
    nit pick: one should use int64 for durations in case int is 32-bit.

    i don't feel too strong about this issue, and i think both solution is
    acceptable to me.
    and i think the performance should be effectively the same (if use
    int64 instead of int).

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Lance Taylor at Jun 19, 2013 at 1:55 pm

    On Wed, Jun 19, 2013 at 6:35 AM, chris dollin wrote:
    I'd feel dimensionally suspect multiplying a Duration by a Duration
    and getting a Duration back.
    Yeah, there is no way to express this sort of dimensional analysis in Go.
    time.Duration(maxOutstanding * int(runTime)) would make me feel
    dimensionally satisfied at the cost of an extra cast.
    That is fine if you find it easier to read. The generated code will
    most likely be the same. Note that you probably want int64 rather
    than int.
    PS "invalid operation" isn't a syntax error, at least in the way I think
    of syntax errors: `maxOutstanding * runTime` is a perfectly
    syntactic expression that happens, by virtue of certain properties
    of the identifiers in it, to be disallowed.
    Agreed, but I think it was you who said it was a syntax error. The
    compiler only said it was an invalid operation, which it is.

    Ian

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Chris dollin at Jun 19, 2013 at 1:58 pm

    On 19 June 2013 14:55, Ian Lance Taylor wrote:
    On Wed, Jun 19, 2013 at 6:35 AM, chris dollin wrote:

    I'd feel dimensionally suspect multiplying a Duration by a Duration
    and getting a Duration back.
    Yeah, there is no way to express this sort of dimensional analysis in Go.
    time.Duration(maxOutstanding * int(runTime)) would make me feel
    dimensionally satisfied at the cost of an extra cast.
    That is fine if you find it easier to read. The generated code will
    most likely be the same. Note that you probably want int64 rather
    than int.
    PS "invalid operation" isn't a syntax error, at least in the way I think
    of syntax errors: `maxOutstanding * runTime` is a perfectly
    syntactic expression that happens, by virtue of certain properties
    of the identifiers in it, to be disallowed.
    Agreed, but I think it was you who said it was a syntax error. The
    compiler only said it was an invalid operation, which it is.

    Ian


    --
    Chris "allusive" Dollin

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Chris dollin at Jun 19, 2013 at 2:00 pm
    OOPS sorry for the previous message ... finger-fumble.

    On 19 June 2013 14:55, Ian Lance Taylor wrote:

    That is fine if you find it easier to read. The generated code will
    most likely be the same. Note that you probably want int64 rather
    than int.
    I used int because the OP (RickyS) had used int.

    PS "invalid operation" isn't a syntax error, at least in the way I think
    of syntax errors: `maxOutstanding * runTime` is a perfectly
    syntactic expression that happens, by virtue of certain properties
    of the identifiers in it, to be disallowed.
    Agreed, but I think it was you who said it was a syntax error. The
    compiler only said it was an invalid operation, which it is.
    RickyS called it a syntax error.

    Chris

    --
    Chris "allusive" Dollin

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • RickyS at Jun 19, 2013 at 3:08 pm
    1. So what's the solution? Casting? I think I can work that out.
        2. The compiler message included the phrase 'mismatched types', which
        sounds like a syntax error to me. Conceptually, I disagree: I think it
        should be allowed.
        3. We can imagine a physics package that allows for time-squared to
        allow coding, as an example, Galileo's Law of Fall,<http://muse.tau.ac.il/museum/galileo/galileo_low_of_fall.html>which involves the square of an elapsed time (the square of a Duration).
        4. The time package has an Add(), I guess I could put that in a loop,
        add the appropriate number of Durations to a Time, and then subtract out
        the original Time. It hurts even to think about this.

    On Wednesday, June 19, 2013 5:00:50 PM UTC+3, chris dollin wrote:

    ...

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Lance Taylor at Jun 19, 2013 at 3:23 pm

    On Wed, Jun 19, 2013 at 8:08 AM, RickyS wrote:
    The compiler message included the phrase 'mismatched types', which sounds
    like a syntax error to me.
    I guess we just disagree on terminology. I would call that a semantic
    error, not a syntax error.
    Conceptually, I disagree: I think it should be
    allowed.
    http://golang.org/doc/faq#conversions

    Ian

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Chris dollin at Jun 19, 2013 at 3:51 pm

    On 19 June 2013 16:08, RickyS wrote:
    1. So what's the solution? Casting? I think I can work that out.

    Conversion, rather than casting, but yes.
    1.
    2. The compiler message included the phrase 'mismatched types', which
    sounds like a syntax error to me. Conceptually, I disagree: I think it
    should be allowed.

    Syntax [IMAO] is about structure, how tokens can be combined to
    make program texts. There wasn't a problem with your token combinations;
    `a * b` is a structurally legal expression. The problem with your
    multiplication is that the types bound to the identifiers don't conform
    to the type rules of the language.

    The type rules aren't rules about token sequences.

    It's /possible/ to mash type rules into the same notation as token
    rules -- witness, for example, Algol 68 -- but that's not the road
    usually taken, for the usual sorts of decoupling reasons. Distinguishing
    token rules from type (and other interpretation) rules is pragmatically
    useful.
    1. We can imagine a physics package that allows for time-squared to
    allow coding, as an example, Galileo's Law of Fall,<http://muse.tau.ac.il/museum/galileo/galileo_low_of_fall.html>which involves the square of an elapsed time (the square of a Duration).
    Oh, sure, but Go's types aren't types that would help with that.

    1. The time package has an Add(), I guess I could put that in a loop,
    add the appropriate number of Durations to a Time, and then subtract out
    the original Time. It hurts even to think about this.

    Multiplication works for this, so long as you account for the types.
    Chris

    --
    Chris "allusive" Dollin

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • RickyS at Jun 19, 2013 at 7:43 pm
    It depends on whether the integer is const or not.
    This program works as expected:
    package main
    import ("fmt"; "time"; "reflect")
    func main () {
       const m = 10
       fmt.Printf("TypeOf(m) is %s\n", reflect.TypeOf(m).Name())
       waiter := time.Duration(3600000000)
       bigwait := m * waiter
       fmt.Printf("waiter is %v, bigwait %v\n", waiter, bigwait)
    }
    The output is:
    TypeOf(m) is int
    waiter is 3.6s, bigwait 36s

    But change the 'const m' to a 'var m' and the old error message returns:
    invalid operation: m * waiter (mismatched types int and time.Duration)
    NOTE: The *const is an int* according to reflection, and the *var is an int
    * according to the error message, so the problem isn't about the type being
    'int', it's about it not being 'const'. The *type rules of the language
    are inconsistent*. At the very least the reflect package should describe
    the const as 'const int' since it actually make a difference.

    Also, there is no way to convert or cast a variable to a const, so that
    path is blocked.

    This also means there is nothing *sensible* for me to convert my variable
    integer to that would allow me to multiply.

    But, if I convert/cast the variable integer to a time.Duration(), I can
    multiply the durations together to get the sensible duration. Problem
    solved at the cost of some time. That is, time squared...

      RickyS

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Jun 19, 2013 at 7:51 pm

    On Thu, Jun 20, 2013 at 3:43 AM, RickyS wrote:

    It depends on whether the integer is const or not.
    This program works as expected:
    package main
    import ("fmt"; "time"; "reflect")
    func main () {
    const m = 10
    fmt.Printf("TypeOf(m) is %s\n", reflect.TypeOf(m).Name())
    waiter := time.Duration(3600000000)
    bigwait := m * waiter
    fmt.Printf("waiter is %v, bigwait %v\n", waiter, bigwait)
    }
    The output is:
    TypeOf(m) is int
    waiter is 3.6s, bigwait 36s

    But change the 'const m' to a 'var m' and the old error message returns:
    invalid operation: m * waiter (mismatched types int and time.Duration)
    NOTE: The *const is an int* according to reflection, and the *var is an
    int* according to the error message, so the problem isn't about the type
    being 'int', it's about it not being 'const'. The *type rules of the
    language are inconsistent*. At the very least the reflect package should
    describe the const as 'const int' since it actually make a difference.
    Go's constant without explicit type are of a special type: untyped constant.

    it will become typed constant (int, time.Duration, float64, complex128, or
    whatever) _only_ when it is used
    (or put it another way, it will have a normal Go type only when it must
    have).

    read more about these rules in the Go spec:
    http://tip.golang.org/ref/spec#Constant_expressions

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • RickyS at Jun 19, 2013 at 9:05 pm
    minux said "it will have a normal Go type only when it must have".
    Well, when multiplying by Duration, it seems to me it *must have* some
    'normal' type.

      RickyS

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Lance Taylor at Jun 19, 2013 at 9:10 pm

    On Wed, Jun 19, 2013 at 2:05 PM, RickyS wrote:
    minux said "it will have a normal Go type only when it must have".
    Well, when multiplying by Duration, it seems to me it must have some
    'normal' type.
    Yes, and that type will be Duration. As the spec says, an untyped
    constant will take on the type appropriate to the expression, if
    possible.

    Ian

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jeremy Wall at Jun 19, 2013 at 7:52 pm

    On Wed, Jun 19, 2013 at 2:43 PM, RickyS wrote:

    It depends on whether the integer is const or not.
    This program works as expected:
    package main
    import ("fmt"; "time"; "reflect")
    func main () {
    const m = 10
    fmt.Printf("TypeOf(m) is %s\n", reflect.TypeOf(m).Name())
    waiter := time.Duration(3600000000)
    bigwait := m * waiter
    fmt.Printf("waiter is %v, bigwait %v\n", waiter, bigwait)
    }
    The output is:
    TypeOf(m) is int
    waiter is 3.6s, bigwait 36s

    But change the 'const m' to a 'var m' and the old error message returns:
    invalid operation: m * waiter (mismatched types int and time.Duration)
    NOTE: The *const is an int* according to reflection, and the *var is an
    int* according to the error message, so the problem isn't about the type
    being 'int', it's about it not being 'const'. The *type rules of the
    language are inconsistent*. At the very least the reflect package should
    describe the const as 'const int' since it actually make a difference.
    Since we are dealing in technicalities here the m is not an int. It's a
    numeric constant. It gets cast to an int when you pass it to the TypeOf
    function.

    Also, there is no way to convert or cast a variable to a const, so that
    path is blocked.

    This also means there is nothing *sensible* for me to convert my variable
    integer to that would allow me to multiply.

    But, if I convert/cast the variable integer to a time.Duration(), I can
    multiply the durations together to get the sensible duration. Problem
    solved at the cost of some time. That is, time squared...

    RickyS

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rob Pike at Jun 19, 2013 at 8:39 pm
    Easier way to print a type: fmt.Printf("%T\n", m)

    (As observed, though, in your case 'm' is not an int, it's a constant,
    but the expression must be given a type when passed to Printf, and
    that type is int)

    -rob

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • RickyS at Jun 19, 2013 at 9:11 pm
    This still doesn't explain how we can multiply a Duration by a 'const' and
    get the answer as if it were an int.
    On Wednesday, June 19, 2013 11:38:40 PM UTC+3, Rob Pike wrote:

    Easier way to print a type: fmt.Printf("%T\n", m)

    (As observed, though, in your case 'm' is not an int, it's a constant,
    but the expression must be given a type when passed to Printf, and
    that type is int)

    -rob
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Lance Taylor at Jun 19, 2013 at 9:13 pm

    On Wed, Jun 19, 2013 at 2:11 PM, RickyS wrote:
    This still doesn't explain how we can multiply a Duration by a 'const' and
    get the answer as if it were an int.
    If you multiply a value of type Duration by an untyped constant, the
    constant will be given the type Duration, and the multiplication will
    be computed in the type Duration and will produce a result of the type
    Duration.

    Ian

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • RickyS at Jun 19, 2013 at 9:32 pm
    What you say is consistent, as the error message (mismatched types)
    re-appears when m is declared as:
    const m int = 100

    But: This means the internal representation of a Duration (or any type) is
    not truly encapsulated. If a Duration were typed as a struct that *
    contained* an int64 then multiplication by a constant would not work,
    either. This breaks my expectations, but my expectations were created by
    using other languages.

    This also means that defining Duration as:
    type Duration int64
    creates Duration as an alias of int64, which the language docs *deny*.
    It's near midnight where I am, so I am going to bed. Good night and thank
    you all very much...

        RickyS
    On Thursday, June 20, 2013 12:13:43 AM UTC+3, Ian Lance Taylor wrote:

    ...
    If you multiply a value of type Duration by an untyped constant, the
    constant will be given the type Duration, and the multiplication will
    be computed in the type Duration and will produce a result of the type
    Duration.

    Ian
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jeremy Wall at Jun 19, 2013 at 9:35 pm

    On Wed, Jun 19, 2013 at 4:32 PM, RickyS wrote:

    What you say is consistent, as the error message (mismatched types)
    re-appears when m is declared as:
    const m int = 100

    But: This means the internal representation of a Duration (or any type) is
    not truly encapsulated. If a Duration were typed as a struct that *
    contained* an int64 then multiplication by a constant would not work,
    either. This breaks my expectations, but my expectations were created by
    using other languages.

    This also means that defining Duration as:
    type Duration int64
    creates Duration as an alias of int64, which the language docs *deny*.
    It's not an alias it's a new type whose base type is int64. It has a
    similar effect as an alias but Go's type system treats the two types as
    seperate and distinct types.

    It's near midnight where I am, so I am going to bed. Good night and thank
    you all very much...

    RickyS
    On Thursday, June 20, 2013 12:13:43 AM UTC+3, Ian Lance Taylor wrote:

    ...

    If you multiply a value of type Duration by an untyped constant, the
    constant will be given the type Duration, and the multiplication will
    be computed in the type Duration and will produce a result of the type
    Duration.

    Ian
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Lance Taylor at Jun 19, 2013 at 9:42 pm

    On Wed, Jun 19, 2013 at 2:32 PM, RickyS wrote:
    But: This means the internal representation of a Duration (or any type) is
    not truly encapsulated.
    That is correct.
    This also means that defining Duration as:
    type Duration int64
    creates Duration as an alias of int64, which the language docs deny.
    In the terminology of the Go spec, a type alias means that two types
    can be used interchangeably. Given the declaration above, that is not
    true of the types Duration and int64. For example, you can not assign
    a value of type int64 to a variable of type Duration.

    There is at present no way for a Go program to declare a type alias,
    but there are two type aliases in the language: byte is an alias for
    uint8, and rune is an alias for uint32.

    Ian

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • peterGo at Jun 19, 2013 at 11:14 pm
    Ian,

    On Wednesday, June 19, 2013 5:42:39 PM UTC-4, Ian Lance Taylor wrote:On
    Wed, Jun 19, 2013 at 2:32 PM, RickyS wrote:
    there are two type aliases in the language: byte is an alias for uint8, and
    rune is an alias for uint32.

    Numeric types
    http://golang.org/ref/spec#Numeric_types

    rune alias for int32

    Peter
    On Wednesday, June 19, 2013 5:42:39 PM UTC-4, Ian Lance Taylor wrote:

    On Wed, Jun 19, 2013 at 2:32 PM, RickyS <rickys...@gmail.com <javascript:>>
    wrote:
    But: This means the internal representation of a Duration (or any type) is
    not truly encapsulated.
    That is correct.
    This also means that defining Duration as:
    type Duration int64
    creates Duration as an alias of int64, which the language docs deny.
    In the terminology of the Go spec, a type alias means that two types
    can be used interchangeably. Given the declaration above, that is not
    true of the types Duration and int64. For example, you can not assign
    a value of type int64 to a variable of type Duration.

    There is at present no way for a Go program to declare a type alias,
    but there are two type aliases in the language: byte is an alias for
    uint8, and rune is an alias for uint32.

    Ian
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • peterGo at Jun 19, 2013 at 11:20 pm
    Correction:

    Ian,

    On Wednesday, June 19, 2013 5:42:39 PM UTC-4, Ian Lance Taylor wrote:
    there are two type aliases in the language: byte is an alias for uint8, and
    rune is an alias for uint32.

    Numeric types
    http://golang.org/ref/spec#Numeric_types

    rune alias for int32

    Peter
    On Wednesday, June 19, 2013 7:14:17 PM UTC-4, peterGo wrote:

    Ian,

    On Wednesday, June 19, 2013 5:42:39 PM UTC-4, Ian Lance Taylor wrote:On
    Wed, Jun 19, 2013 at 2:32 PM, RickyS wrote:
    there are two type aliases in the language: byte is an alias for uint8,
    and rune is an alias for uint32.

    Numeric types
    http://golang.org/ref/spec#Numeric_types

    rune alias for int32

    Peter
    On Wednesday, June 19, 2013 5:42:39 PM UTC-4, Ian Lance Taylor wrote:
    On Wed, Jun 19, 2013 at 2:32 PM, RickyS wrote:

    But: This means the internal representation of a Duration (or any type) is
    not truly encapsulated.
    That is correct.
    This also means that defining Duration as:
    type Duration int64
    creates Duration as an alias of int64, which the language docs deny.
    In the terminology of the Go spec, a type alias means that two types
    can be used interchangeably. Given the declaration above, that is not
    true of the types Duration and int64. For example, you can not assign
    a value of type int64 to a variable of type Duration.

    There is at present no way for a Go program to declare a type alias,
    but there are two type aliases in the language: byte is an alias for
    uint8, and rune is an alias for uint32.

    Ian
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Lance Taylor at Jun 19, 2013 at 11:32 pm

    On Wed, Jun 19, 2013 at 4:14 PM, peterGo wrote:
    On Wednesday, June 19, 2013 5:42:39 PM UTC-4, Ian Lance Taylor wrote:On Wed,
    Jun 19, 2013 at 2:32 PM, RickyS wrote:
    there are two type aliases in the language: byte is an alias for uint8, and
    rune is an alias for uint32.

    Numeric types
    http://golang.org/ref/spec#Numeric_types

    rune alias for int32
    Right, thanks for the correction.

    Ian

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Jun 19, 2013 at 9:42 pm

    On Thu, Jun 20, 2013 at 5:32 AM, RickyS wrote:

    What you say is consistent, as the error message (mismatched types)
    re-appears when m is declared as:
    const m int = 100
    this is not an untyped constant, so that conversion to a suitable type rule
    doesn't apply anymore.
    But: This means the internal representation of a Duration (or any type) is
    not truly encapsulated. If a Duration were typed as a struct that *
    contained* an int64 then multiplication by a constant would not work,
    either. This breaks my expectations, but my expectations were created by
    using other languages.

    This also means that defining Duration as:
    type Duration int64
    creates Duration as an alias of int64, which the language docs *deny*.
    it doesn't create an alias, it's a new type that happens to share the
    arithmetic rules of int64.

    the rule for Go multiplication is pretty simple, just one rule, both side
    must be of the same type.

    constant could be either typed (like your m above), or untyped (when you
    say `const m = 100`),
    when an untyped constant is used in an expression, say, m *
    time.Duration(100), then it must
    have a type, and as the other side of the expression is typed
    time.Duration, it is typed time.Duration.

    this explains why:
    100 * time.Duration(100) works, and also
    when m is: const m = 100, m * time.Duration(100) works.
    but when m is: const m int = 100, m * time.Duration(100) won't compile.

    even if you declare m as: const m int64 = 100, m * time.Duration(100) is
    still an error.
    the only way (if you intend to give m a type at the time of declaration),
    is:
    const m time.Duration = 100

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • RickyS at Jun 19, 2013 at 9:08 pm
    If Jeremy Wall is right, and it seems to me he is, then TypeOf (and
    reflection) should *be in the language and not a package*.
    On Wednesday, June 19, 2013 10:52:08 PM UTC+3, Jeremy Wall wrote:


    Since we are dealing in technicalities here the m is not an int. It's a
    numeric constant. It gets cast to an int when you pass it to the TypeOf
    function.

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jeremy Wall at Jun 19, 2013 at 9:11 pm

    On Wed, Jun 19, 2013 at 4:08 PM, RickyS wrote:

    If Jeremy Wall is right, and it seems to me he is, then TypeOf (and
    reflection) should *be in the language and not a package*.

    I'm not sure that really helps. Go constants are not typed in the sense
    that a variable is. TypeOf for a constant doesn't really make sense.

    On Wednesday, June 19, 2013 10:52:08 PM UTC+3, Jeremy Wall wrote:


    Since we are dealing in technicalities here the m is not an int. It's a
    numeric constant. It gets cast to an int when you pass it to the TypeOf
    function.

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Lance Taylor at Jun 19, 2013 at 9:12 pm

    On Wed, Jun 19, 2013 at 2:08 PM, RickyS wrote:
    If Jeremy Wall is right, and it seems to me he is, then TypeOf (and
    reflection) should be in the language and not a package.
    Why? Untyped constants are a purely compile-time construct, required
    to make Go's strict type rules work. They don't exist at runtime. At
    runtime, everything has a type.

    (Actually, TypeOf was in the language in the past--it used to be
    unsafe.TypeOf--but we moved it into the reflect package when we
    realized that it was only useful as part of reflect.)

    Ian

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • William Kennedy at Jun 19, 2013 at 11:13 pm
    Hi Ricky,
    Check out my blog on the subject, it might be of some help
    http://www.goinggo.net/2013/06/gos-duration-type-unravelled.html
    On Wednesday, June 19, 2013 9:22:44 AM UTC-4, RickyS wrote:

    I've calculated an interval as a time.Duration. I want to print out a
    Duration that is 100 (for example) times as long?

    The obvious expression gets a syntax error:
    * invalid operation: maxOutstanding * runTime (mismatched types int and
    time.Duration)*

    Using go 1.1.1

    Thanks,
    Ricky
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJun 19, '13 at 1:22p
activeJun 19, '13 at 11:32p
posts29
users8
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase