FAQ
Hi golang-dev

I've followed golang-nuts closely for some years now and I think I
understand what people want when they fight about generics and what the Go
team is willing to implement.

Therefore I have created a little specification that gives Go better
generic capabilities while not breaking the Go 1 promise.

https://docs.google.com/document/d/19eOnP0OE39oM0u91wtaB8hdccYRGEC8nN6hiE352n-4/edit#

(I am unsure if I should give editing rights to "anyone with the link"
because of crawlers but I have activated comments.)

Please take a look and tell me your opinion.

Thank you,
- Tom

--

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

Search Discussions

  • Ian Lance Taylor at Jun 19, 2013 at 9:05 pm

    On Wed, Jun 19, 2013 at 1:42 PM, wrote:
    I've followed golang-nuts closely for some years now and I think I
    understand what people want when they fight about generics and what the Go
    team is willing to implement.

    Therefore I have created a little specification that gives Go better generic
    capabilities while not breaking the Go 1 promise.

    https://docs.google.com/document/d/19eOnP0OE39oM0u91wtaB8hdccYRGEC8nN6hiE352n-4/edit#
    Thanks. I don't see a consideration of data representation issues.
    For example, it's easy to say that we permit treating a []interface{}
    as []string. But those two types have different representations. If
    you pass a []interface{} to a function that expects a []string, the
    wrong thing will happen. Somewhere, somehow, there needs to be a
    conversion. Where, and how?

    Ian

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Tomwilde at Jun 19, 2013 at 9:22 pm
    Hi Ian,


    thanks for your quick reply.

    Let me start by saying that I'm in no way a compiler expert but I'll give
    my best to make sense here:

    I'll assume that slice access is dynamic since the runtime performs a
    boundary-check. I'll also assume that an interface is a fixed-size value.

    Since slice access is already dynamic wouldn't the cost of also looking up
    its elements' size by checking the type info be relatively moderate?

    - Tom

    On Wednesday, June 19, 2013 11:05:06 PM UTC+2, Ian Lance Taylor wrote:

    On Wed, Jun 19, 2013 at 1:42 PM, <sedevel...@gmail.com <javascript:>>
    wrote:
    I've followed golang-nuts closely for some years now and I think I
    understand what people want when they fight about generics and what the Go
    team is willing to implement.

    Therefore I have created a little specification that gives Go better generic
    capabilities while not breaking the Go 1 promise.
    https://docs.google.com/document/d/19eOnP0OE39oM0u91wtaB8hdccYRGEC8nN6hiE352n-4/edit#

    Thanks. I don't see a consideration of data representation issues.
    For example, it's easy to say that we permit treating a []interface{}
    as []string. But those two types have different representations. If
    you pass a []interface{} to a function that expects a []string, the
    wrong thing will happen. Somewhere, somehow, there needs to be a
    conversion. Where, and how?

    Ian
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Lance Taylor at Jun 19, 2013 at 9:33 pm

    On Wed, Jun 19, 2013 at 2:22 PM, tomwilde wrote:
    I'll assume that slice access is dynamic since the runtime performs a
    boundary-check. I'll also assume that an interface is a fixed-size value.

    Since slice access is already dynamic wouldn't the cost of also looking up
    its elements' size by checking the type info be relatively moderate?
    It's not impossible but I expect that it would be a measurable runtime
    hit. Right now, if s is a slice, evaluating s[i] is multiplication by
    a constant. You seem to be suggesting that we rewrite s[i] to locate
    the type information, load the size, and then do a multiplication by a
    value loaded from memory. It's not clear to me how we locate the type
    information; currently a slice does not contain the type information,
    so it would have to be available somewhere, and I don't know where.
    But anyhow it's going to be, I think, two memory loads plus a register
    multiplication. That's quite a bit slower than a multiplication by a
    constant, which can normally be implemented as a shift instruction.
    As I say, it's not impossible, but it's going to be visible.

    And now that I've written that I'm concerned by finding the type of
    the slice. Where is that going to come from?

    I don't mean to dump on your idea, it's interesting and may be worth
    pursuing. But without a clear understand of the data representation,
    I don't know how to evaluate it.

    Ian

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Tomwilde at Jun 20, 2013 at 9:37 am
    Ian,

    I have been thinking about this. Would it make sense to open a proposal
    round for the data representation issue?
    And considering the rest of the spec - what do you think - can any other of
    the ideas be implemented fairly easily?

    All the best,
    - Tom
    On Wednesday, June 19, 2013 11:33:13 PM UTC+2, Ian Lance Taylor wrote:
    On Wed, Jun 19, 2013 at 2:22 PM, tomwilde wrote:

    I'll assume that slice access is dynamic since the runtime performs a
    boundary-check. I'll also assume that an interface is a fixed-size value.
    Since slice access is already dynamic wouldn't the cost of also looking up
    its elements' size by checking the type info be relatively moderate?
    It's not impossible but I expect that it would be a measurable runtime
    hit. Right now, if s is a slice, evaluating s[i] is multiplication by
    a constant. You seem to be suggesting that we rewrite s[i] to locate
    the type information, load the size, and then do a multiplication by a
    value loaded from memory. It's not clear to me how we locate the type
    information; currently a slice does not contain the type information,
    so it would have to be available somewhere, and I don't know where.
    But anyhow it's going to be, I think, two memory loads plus a register
    multiplication. That's quite a bit slower than a multiplication by a
    constant, which can normally be implemented as a shift instruction.
    As I say, it's not impossible, but it's going to be visible.

    And now that I've written that I'm concerned by finding the type of
    the slice. Where is that going to come from?

    I don't mean to dump on your idea, it's interesting and may be worth
    pursuing. But without a clear understand of the data representation,
    I don't know how to evaluate it.

    Ian
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Lance Taylor at Jun 20, 2013 at 4:54 pm

    On Thu, Jun 20, 2013 at 2:37 AM, tomwilde wrote:
    I have been thinking about this. Would it make sense to open a proposal
    round for the data representation issue?
    And considering the rest of the spec - what do you think - can any other of
    the ideas be implemented fairly easily?
    I can't really think about a proposal for generics without thinking
    about the data representation and about how the code is compiled. For
    me those are fundamental issues, and they are closely tied to the
    semantics.

    Ian

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Sambeau at Jun 21, 2013 at 12:28 pm
    Correction:

    :
    eventually you get a match and code
    :
    (a uint8, b uint16) *real* {
    return uint16(a) + b
    }

    should probably be

    :
    eventually you get a match and code
    :
    (a uint8, b uint16) *uint16* {
    return uint16(a) + b
    }

    but I may need to think about it some more :)

    *(this stuff is hard)*

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Sambeau at Jun 21, 2013 at 12:28 pm
    I'd prefer to see something more akin to this:

    define the types as logical unions

    type uint (uint8 | uint16 | uint32 | uint64)
    type sint (int8 | int16 | int32 | int64)
    type int (uint| sint)
    type float (float32 | float64)
    type real (float | int)

    explicitly mention each type signature you want the compiler to recognise
    with rules, a little like BNF:

    function add(a,b real)
    add(a,b int)
    add(a,b float)
    function add(a,b int)
    add(a,b uint)
    add(a,b sint)
    function add(a,b uint)
    add(a,b uint8)
    add(a,b uint16)
    add(a,b uint32)
    add(a,b uint64)
    :
    eventually you get a match and code
    :
    (a uint8, b uint16) real {
    return uint16(a) + b
    }


    If a rule the generic type is marked it has to be the same sub-type


    function max(a,b ~real) ~real {
    if(a > b){
    return a
    }
    return b
    }

    or possibly

    function max(a,b R~real) R~real {
    if(a > b){
    return a
    }
    return b
    }

    for the occasions when you have more than one type being repeated.

    Also the possibility of sany tyoe as long as its the same type:

    function swap(a,b ~interface){
    temp := a
    a = b
    b = temp
    }

    or maybe:

    function swap(a,b F~){
    F temp = a
    a = b
    b = temp
    }

    The compiler doesn't compile anything it can't match the types of.

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Tomwilde at Jun 21, 2013 at 3:33 pm
    Hi Sam,

    I appreciate your contribution to the thread.
    Yet I'm proposing a solution which is Go 1 compatible - not changing the
    language.
    My reason to do so is that I agree with the Go authors that the language
    should be kept simple.
    New syntax is a no-go in the scope of this proposal.

    Cheers,
    Tom
    On Friday, June 21, 2013 12:24:35 PM UTC+2, sam...@gmail.com wrote:

    I'd prefer to see something more akin to this:

    define the types as logical unions

    type uint (uint8 | uint16 | uint32 | uint64)
    type sint (int8 | int16 | int32 | int64)
    type int (uint| sint)
    type float (float32 | float64)
    type real (float | int)

    explicitly mention each type signature you want the compiler to recognise
    with rules, a little like BNF:

    function add(a,b real)
    add(a,b int)
    add(a,b float)
    function add(a,b int)
    add(a,b uint)
    add(a,b sint)
    function add(a,b uint)
    add(a,b uint8)
    add(a,b uint16)
    add(a,b uint32)
    add(a,b uint64)
    :
    eventually you get a match and code
    :
    (a uint8, b uint16) real {
    return uint16(a) + b
    }


    If a rule the generic type is marked it has to be the same sub-type


    function max(a,b ~real) ~real {
    if(a > b){
    return a
    }
    return b
    }

    or possibly

    function max(a,b R~real) R~real {
    if(a > b){
    return a
    }
    return b
    }

    for the occasions when you have more than one type being repeated.

    Also the possibility of sany tyoe as long as its the same type:

    function swap(a,b ~interface){
    temp := a
    a = b
    b = temp
    }

    or maybe:

    function swap(a,b F~){
    F temp = a
    a = b
    b = temp
    }

    The compiler doesn't compile anything it can't match the types of.
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rémy Oudompheng at Jun 21, 2013 at 3:46 pm

    2013/6/21 tomwilde <sedevelopers01@gmail.com>:
    Hi Sam,

    I appreciate your contribution to the thread.
    Yet I'm proposing a solution which is Go 1 compatible - not changing the
    language.
    My reason to do so is that I agree with the Go authors that the language
    should be kept simple.
    New syntax is a no-go in the scope of this proposal.
    You are proposing (through covariance) to modify a fundamental aspect
    of the language by suggesting by "func() interface{}" become an
    interface-like type: func() int in your proposal is transparently
    assignable to func() interface{}, and func() interface{} is
    type-assertable to func() int, and similarly for the rest of the type
    algebra.

    This contradicts a fundamental aspect of Go's type system in which
    only interface types can be type-asserted.

    The rule of type assertions become incredibly complicated in this
    proposal, both programmer-wise and computer-wise, if you introduce
    such a concept. I don't understand how you can think the proposal is
    compatible with keeping the language simple.

    Also, your StringStore example goes the wrong way compared to general
    covariance/contravariance ideas, and looks out of place.

    Regards
    Rémy.

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Tomwilde at Jun 21, 2013 at 4:16 pm

    You are proposing (through covariance) to modify a fundamental aspect
    of the language by suggesting by "func() interface{}" become an
    interface-like type: func() int in your proposal is transparently
    assignable to func() interface{}, and func() interface{} is
    type-assertable to func() int, and similarly for the rest of the type
    algebra.

    This contradicts a fundamental aspect of Go's type system in which
    only interface types can be type-asserted.
    You are right, I have changed the example to better reflect the intent.

    Also, your StringStore example goes the wrong way compared to general
    covariance/contravariance ideas, and looks out of place.
    Why? Covariance: A StringStore is a Store.

    Thanks for the valuable input.

    - Tom

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rémy Oudompheng at Jun 21, 2013 at 4:25 pm

    On 2013/6/21 tomwilde wrote:
    You are proposing (through covariance) to modify a fundamental aspect
    of the language by suggesting by "func() interface{}" become an
    interface-like type: func() int in your proposal is transparently
    assignable to func() interface{}, and func() interface{} is
    type-assertable to func() int, and similarly for the rest of the type
    algebra.

    This contradicts a fundamental aspect of Go's type system in which
    only interface types can be type-asserted.

    You are right, I have changed the example to better reflect the intent.
    I don't understand this statement. Which example? I'm saying that the
    very idea looks wrong.
    Also, your StringStore example goes the wrong way compared to general
    covariance/contravariance ideas, and looks out of place.

    Why? Covariance: A StringStore is a Store.
    Covariance doesn't make sense here: a StringStore stores strings, a
    Store stores anything. So a StringStore is not a Store because it
    doesn't store integers.

    Rémy.

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Niklas Schnelle at Jun 20, 2013 at 12:10 pm
    Hi tomwilde,

    I just wanted to add that from my understanding the bounds checks on arrays
    don't mean that there is anything dynamic about the access.
    One of the great things about static bounds checks directly in the compiler
    is the fact that for the especially costly case of access in a for loop
    bounds checks
    can nearly always be reduced to a single check. As I understand it
    accessing an element of an []interface{} slice or any other slice for that
    matter is just like
    a C array access. In the case of an interface value as I understand it the
    current implementation basically uses a struct of two pointers, one being
    the pointer to the type
    of the concrete value and the other one being either an embedded value or a
    pointer to the value, again this is not really dynamic, the only dynamic
    part is vtable lookup of
    methods which as far as I understand it is pretty similiar to what C++ does.
    I personally really dislike Java's notion of generics which is a really bad
    example of glueing things on after the fact, it's basically static type
    checking for
    Object values and even that is done pretty badly. I'd say that the most
    usefull version of generics is purely compile time templates like in C++.
    However C++
    offers so many features that it's template system is really complicated to
    the point where it's turing complete and you can use
    template matching to compute stuff at compile time.
    At one point a friend used that to compute a list of initial primes for a
    prime sieve at compile time and when you computed the first 1000 primes it
    would only work with the
    then latest gcc version and take >8 GB of memory to compile.
    One interesting generic implementation is that of Ada which as far as I
    know is compile time as well but tends not to be misued.
      See https://en.wikibooks.org/wiki/Ada_Programming/Generics

    On Wednesday, June 19, 2013 11:22:51 PM UTC+2, tomwilde wrote:

    Hi Ian,


    thanks for your quick reply.

    Let me start by saying that I'm in no way a compiler expert but I'll give
    my best to make sense here:

    I'll assume that slice access is dynamic since the runtime performs a
    boundary-check. I'll also assume that an interface is a fixed-size value.

    Since slice access is already dynamic wouldn't the cost of also looking up
    its elements' size by checking the type info be relatively moderate?

    - Tom

    On Wednesday, June 19, 2013 11:05:06 PM UTC+2, Ian Lance Taylor wrote:
    On Wed, Jun 19, 2013 at 1:42 PM, wrote:

    I've followed golang-nuts closely for some years now and I think I
    understand what people want when they fight about generics and what the Go
    team is willing to implement.

    Therefore I have created a little specification that gives Go better generic
    capabilities while not breaking the Go 1 promise.
    https://docs.google.com/document/d/19eOnP0OE39oM0u91wtaB8hdccYRGEC8nN6hiE352n-4/edit#

    Thanks. I don't see a consideration of data representation issues.
    For example, it's easy to say that we permit treating a []interface{}
    as []string. But those two types have different representations. If
    you pass a []interface{} to a function that expects a []string, the
    wrong thing will happen. Somewhere, somehow, there needs to be a
    conversion. Where, and how?

    Ian
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rémy Oudompheng at Jun 19, 2013 at 10:20 pm

    On 2013/6/19 wrote:
    Hi golang-dev

    I've followed golang-nuts closely for some years now and I think I
    understand what people want when they fight about generics and what the Go
    team is willing to implement.

    Therefore I have created a little specification that gives Go better generic
    capabilities while not breaking the Go 1 promise.

    https://docs.google.com/document/d/19eOnP0OE39oM0u91wtaB8hdccYRGEC8nN6hiE352n-4/edit#

    (I am unsure if I should give editing rights to "anyone with the link"
    because of crawlers but I have activated comments.)

    Please take a look and tell me your opinion.
    Hello,

    As said by Ian, your document suggests a kind of specification, but
    not ideas about what an implementation could look like (at compile
    time, at run time). A generics proposal must consider both in order to
    look realistic.

    You may also have noticed that many discussions have already been done
    on the subject. I have wanted for a long time to have a document
    gathering what people have said in order to avoid redundancy: so I
    sketched something at:
       https://github.com/remyoudompheng/go-misc/blob/master/generics/generics.markdown

    It can be enriched with the various things, remarks, issues proposals
    that were already made in order to make things easier to evaluate. At
    the moment I have only put a few obvious things that came in mind.

    Rémy.

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Jun 20, 2013 at 3:27 am
    I agree it's important to maintain a canonical list of generics proposals
    by category. Even better would be the addition of a table with each
    developed proposal, listing the categories of generics that it attempts to
    solve, and perhaps an objective set of columns to give a numeric rating for
    each of 1) degree of compatibility breakage (ranging from none to severe),
    2) degree of syntactic change (ranging from none [semantic only] to
    severe), 2) degree of semantic impact (minimal if completely orthogonal to
    other language features), 3) expected dynamic (runtime) cost (may be N/A if
    purely compile-time), 4) expected static (such as binary size) cost, and 5)
    implementation feasibility (ranging from impossible to trivial). #3-5 could
    be repeated for multiple implementation strategies of the same proposal.

    Regarding your generic 'reverse' implementation: as coded, it's actually a
    double reverse, or a 'busy no-op', depending on how you want to look at it.
    I think you really mean for the loop to range over `slice[:len(slice)/2]`.
    On Wednesday, June 19, 2013 4:20:58 PM UTC-6, Rémy wrote:
    On 2013/6/19 <sedevel...@gmail.com <javascript:>> wrote:
    Hi golang-dev

    I've followed golang-nuts closely for some years now and I think I
    understand what people want when they fight about generics and what the Go
    team is willing to implement.

    Therefore I have created a little specification that gives Go better generic
    capabilities while not breaking the Go 1 promise.

    https://docs.google.com/document/d/19eOnP0OE39oM0u91wtaB8hdccYRGEC8nN6hiE352n-4/edit#
    (I am unsure if I should give editing rights to "anyone with the link"
    because of crawlers but I have activated comments.)

    Please take a look and tell me your opinion.
    Hello,

    As said by Ian, your document suggests a kind of specification, but
    not ideas about what an implementation could look like (at compile
    time, at run time). A generics proposal must consider both in order to
    look realistic.

    You may also have noticed that many discussions have already been done
    on the subject. I have wanted for a long time to have a document
    gathering what people have said in order to avoid redundancy: so I
    sketched something at:

    https://github.com/remyoudompheng/go-misc/blob/master/generics/generics.markdown

    It can be enriched with the various things, remarks, issues proposals
    that were already made in order to make things easier to evaluate. At
    the moment I have only put a few obvious things that came in mind.

    Rémy.
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Tomwilde at Jun 20, 2013 at 9:47 am
    Hi Kevin,

    before starting to coding your idea into a web application, I'd like to
    hear the opinion of the Go team because it is my believe that most of the
    ideas that have been proposed up to now are not even close to what they
    would be willing to consider to implement.

    One consequence that shouldn't be overlooked is that some functions that
    accept some variety of interface{} or []interface{} (or...) aren't really
    intended to accept "anything", but rather only a few types which are then
    type-asserted.
    Good catch! If you have an idea about how we could express that in a more
    concise way in the language and without breaking the Go 1 promise then
    please send me an email and Ill gladly integrate it into the proposal.

    Cheers,
    - Tom
    On Thursday, June 20, 2013 5:27:18 AM UTC+2, Kevin Gillette wrote:

    I agree it's important to maintain a canonical list of generics proposals
    by category. Even better would be the addition of a table with each
    developed proposal, listing the categories of generics that it attempts to
    solve, and perhaps an objective set of columns to give a numeric rating for
    each of 1) degree of compatibility breakage (ranging from none to severe),
    2) degree of syntactic change (ranging from none [semantic only] to
    severe), 2) degree of semantic impact (minimal if completely orthogonal to
    other language features), 3) expected dynamic (runtime) cost (may be N/A if
    purely compile-time), 4) expected static (such as binary size) cost, and 5)
    implementation feasibility (ranging from impossible to trivial). #3-5 could
    be repeated for multiple implementation strategies of the same proposal.

    Regarding your generic 'reverse' implementation: as coded, it's actually a
    double reverse, or a 'busy no-op', depending on how you want to look at it.
    I think you really mean for the loop to range over `slice[:len(slice)/2]`.
    On Wednesday, June 19, 2013 4:20:58 PM UTC-6, Rémy wrote:
    On 2013/6/19 wrote:
    Hi golang-dev

    I've followed golang-nuts closely for some years now and I think I
    understand what people want when they fight about generics and what the Go
    team is willing to implement.

    Therefore I have created a little specification that gives Go better generic
    capabilities while not breaking the Go 1 promise.

    https://docs.google.com/document/d/19eOnP0OE39oM0u91wtaB8hdccYRGEC8nN6hiE352n-4/edit#
    (I am unsure if I should give editing rights to "anyone with the link"
    because of crawlers but I have activated comments.)

    Please take a look and tell me your opinion.
    Hello,

    As said by Ian, your document suggests a kind of specification, but
    not ideas about what an implementation could look like (at compile
    time, at run time). A generics proposal must consider both in order to
    look realistic.

    You may also have noticed that many discussions have already been done
    on the subject. I have wanted for a long time to have a document
    gathering what people have said in order to avoid redundancy: so I
    sketched something at:

    https://github.com/remyoudompheng/go-misc/blob/master/generics/generics.markdown

    It can be enriched with the various things, remarks, issues proposals
    that were already made in order to make things easier to evaluate. At
    the moment I have only put a few obvious things that came in mind.

    Rémy.
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Tomwilde at Jun 20, 2013 at 9:41 am
    Hi Remy,

    I appreciate your engagement in this topic and I have read through your
    list.
    You are right that this discussion has gone on for too long and mostly with
    API-breaking ideas adopted from other languages.
    This is why this proposal was carefully written to not break the Go 1
    promise and fit well to the language as it exists now.
    If you'd like, I will gladly integrate the points described in your
    document to my document - as long as it follows the ground rules of
    backward-compatibility.
    You are also welcome to copy my proposal into your list.

    cheers,
    - Tom
    On Thursday, June 20, 2013 12:20:58 AM UTC+2, Rémy wrote:
    On 2013/6/19 <sedevel...@gmail.com <javascript:>> wrote:
    Hi golang-dev

    I've followed golang-nuts closely for some years now and I think I
    understand what people want when they fight about generics and what the Go
    team is willing to implement.

    Therefore I have created a little specification that gives Go better generic
    capabilities while not breaking the Go 1 promise.

    https://docs.google.com/document/d/19eOnP0OE39oM0u91wtaB8hdccYRGEC8nN6hiE352n-4/edit#
    (I am unsure if I should give editing rights to "anyone with the link"
    because of crawlers but I have activated comments.)

    Please take a look and tell me your opinion.
    Hello,

    As said by Ian, your document suggests a kind of specification, but
    not ideas about what an implementation could look like (at compile
    time, at run time). A generics proposal must consider both in order to
    look realistic.

    You may also have noticed that many discussions have already been done
    on the subject. I have wanted for a long time to have a document
    gathering what people have said in order to avoid redundancy: so I
    sketched something at:

    https://github.com/remyoudompheng/go-misc/blob/master/generics/generics.markdown

    It can be enriched with the various things, remarks, issues proposals
    that were already made in order to make things easier to evaluate. At
    the moment I have only put a few obvious things that came in mind.

    Rémy.
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kyle Lemons at Jun 20, 2013 at 3:33 pm

    On Thu, Jun 20, 2013 at 2:41 AM, tomwilde wrote:

    Hi Remy,

    I appreciate your engagement in this topic and I have read through your
    list.
    You are right that this discussion has gone on for too long and mostly
    with API-breaking ideas adopted from other languages.
    This is why this proposal was carefully written to not break the Go 1
    promise and fit well to the language as it exists now.
    I have to admit, not breaking the go1 API compatibility promise seems like
    a non-goal to me. As long as gofix can address a majority of the changes
    and identify most of the others, I'm usually cool with it. One major
    selling point of generics would be the ability to consolidate strings/bytes
    and math/cmath and make the math package work equally well for all flavors
    of numeric type; all of which breaks the go1 API compatibility promise. I
    would be very surprised if generics were added before go2.

    If you'd like, I will gladly integrate the points described in your
    document to my document - as long as it follows the ground rules of
    backward-compatibility.
    You are also welcome to copy my proposal into your list.

    cheers,
    - Tom
    On Thursday, June 20, 2013 12:20:58 AM UTC+2, Rémy wrote:
    On 2013/6/19 wrote:
    Hi golang-dev

    I've followed golang-nuts closely for some years now and I think I
    understand what people want when they fight about generics and what the Go
    team is willing to implement.

    Therefore I have created a little specification that gives Go better generic
    capabilities while not breaking the Go 1 promise.

    https://docs.google.com/**document/d/**19eOnP0OE39oM0u91wtaB8hdccYRGE**
    C8nN6hiE352n-4/edit#<https://docs.google.com/document/d/19eOnP0OE39oM0u91wtaB8hdccYRGEC8nN6hiE352n-4/edit#>
    (I am unsure if I should give editing rights to "anyone with the link"
    because of crawlers but I have activated comments.)

    Please take a look and tell me your opinion.
    Hello,

    As said by Ian, your document suggests a kind of specification, but
    not ideas about what an implementation could look like (at compile
    time, at run time). A generics proposal must consider both in order to
    look realistic.

    You may also have noticed that many discussions have already been done
    on the subject. I have wanted for a long time to have a document
    gathering what people have said in order to avoid redundancy: so I
    sketched something at:
    https://github.com/**remyoudompheng/go-misc/blob/**
    master/generics/generics.**markdown<https://github.com/remyoudompheng/go-misc/blob/master/generics/generics.markdown>

    It can be enriched with the various things, remarks, issues proposals
    that were already made in order to make things easier to evaluate. At
    the moment I have only put a few obvious things that came in mind.

    Rémy.
    --

    ---
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+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-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Jun 20, 2013 at 3:40 am
    One consequence that shouldn't be overlooked is that some functions that
    accept some variety of interface{} or []interface{} (or...) aren't really
    intended to accept "anything", but rather only a few types which are then
    type-asserted. This proposal would allow, e.g.

    package a

    func MutateIntOrFloat(value interface{}) interface{} { ... }

    package b

    type Mutator func(interface{}) interface{}

    func MakeStringMutator(f Mutator) func(string) string {
         return func(s string) string {
             return f(s)
         }
    }

    In this way, functions can be arbitrarily masked and proxied in ways that
    compile with static types (and thus feel safe), but blow up at runtime.
    While that can be done now with reflect or explicit type assertion, the
    effort involved tends to make the programmer well aware of the runtime
    dangers involved. Easing this burden, while not a problem in itself, makes
    it more likely that programmers would take certain liberties with the code
    they consume and produce in ways that produce less reliable software -- to
    fix that, we'd also have to address the issue of programmers using
    interface{} in places where they don't actually mean 'anything and
    everything'; unions would be one such hypothetical solution.
    On Wednesday, June 19, 2013 2:42:10 PM UTC-6, tomwilde wrote:

    Hi golang-dev

    I've followed golang-nuts closely for some years now and I think I
    understand what people want when they fight about generics and what the Go
    team is willing to implement.

    Therefore I have created a little specification that gives Go better
    generic capabilities while not breaking the Go 1 promise.


    https://docs.google.com/document/d/19eOnP0OE39oM0u91wtaB8hdccYRGEC8nN6hiE352n-4/edit#

    (I am unsure if I should give editing rights to "anyone with the link"
    because of crawlers but I have activated comments.)

    Please take a look and tell me your opinion.

    Thank you,
    - Tom
    --

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedJun 19, '13 at 9:00p
activeJun 21, '13 at 4:25p
posts19
users7
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase