FAQ
Hi All,

we all know that one complain about go is the lack of *generics*.

However in `real life`, we don't miss them so often.

There are still cases we all like to have some kind of `generic` type.

To partially solve this problem we workaround using interfaces{} as input
parameters with type assertions, or we wrap a interface around a custom
type.

So I came up with a simple idea: *type family*

Type family should respect two laws:

1. Can't be allocated
2. Acts as real type

Basically given a *type family*:

type Unit (byte, rune)

type Units (
[]Unit,
string
)


Can be read as:

Unit is a *type *(family) that can be: *byte *or *rune*
Units is a *type *(family) that can be: *[]Unit* or *String*

In this way we can build a `generic function` like:

func insertAt(s Units, c Unit, i int) Units {
s = append(s, 0)
copy(s[i+1:], s[i:])
s[i] = c
return s
}

This reads as: Insert is a function that accepts a source *s *of type *Units,
*a *c *of type *Unit *and returns (the modified s): *Units.*

We can use this function in a pseudo generic way as:

a := "Hello World"
b := []byte(a)
c := []rune(a)

insertAt(a, "a", 10)
insertAt(b, '!', 10)
insertAt(c, '!', 10)

I think this is very easy to implement, we just need to update the grammar
and the parser to type check the family with an *OR* condition. Without
losing the precious type check of the compiler.

The solution keeps go-lang still very clean and simple and doesn't affect
the current code.

What do you think?

Cheers,
DAddYE

--
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/d/optout.

Search Discussions

  • Andrewchamberss at Jul 13, 2014 at 11:37 pm
    I'm guilty of this too, but I've realized we should really keep these types
    of proposals to golang-nuts (I see you have posted there too) at least
    until the idea has been discussed more and maybe had a highly positive
    response by a majority of people.

    There are a few reasons:

    1. The official language isn't going to change at all for a while, so no
    proposal like this requires any code work. Therefore it doesn't really need
    to be on the dev list.
    2. This proposal in particular isn't really fully formed, I can see a few
    problems, so even if it's a good idea, won't require any dev work yet..
    3. The decision makers do actually read golang-nuts even if they don't
    always reply. You can rest assured a good idea won't go totally unread.

    Not trying to dismiss your ideas. It's just the other proposals from that
    are currently active on the dev list are fairly extensive and well
    specified, are tooling changes and not language changes and are coming from
    people who directly influence and control the official Go specs.

    On Monday, July 14, 2014 5:32:12 AM UTC+12, Davide D'Agostino wrote:

    Hi All,

    we all know that one complain about go is the lack of *generics*.

    However in `real life`, we don't miss them so often.

    There are still cases we all like to have some kind of `generic` type.

    To partially solve this problem we workaround using interfaces{} as input
    parameters with type assertions, or we wrap a interface around a custom
    type.

    So I came up with a simple idea: *type family*

    Type family should respect two laws:

    1. Can't be allocated
    2. Acts as real type

    Basically given a *type family*:

    type Unit (byte, rune)

    type Units (
    []Unit,
    string
    )


    Can be read as:

    Unit is a *type *(family) that can be: *byte *or *rune*
    Units is a *type *(family) that can be: *[]Unit* or *String*

    In this way we can build a `generic function` like:

    func insertAt(s Units, c Unit, i int) Units {
    s = append(s, 0)
    copy(s[i+1:], s[i:])
    s[i] = c
    return s
    }

    This reads as: Insert is a function that accepts a source *s *of type *Units,
    *a *c *of type *Unit *and returns (the modified s): *Units.*

    We can use this function in a pseudo generic way as:

    a := "Hello World"
    b := []byte(a)
    c := []rune(a)

    insertAt(a, "a", 10)
    insertAt(b, '!', 10)
    insertAt(c, '!', 10)

    I think this is very easy to implement, we just need to update the grammar
    and the parser to type check the family with an *OR* condition. Without
    losing the precious type check of the compiler.

    The solution keeps go-lang still very clean and simple and doesn't affect
    the current code.

    What do you think?

    Cheers,
    DAddYE
    --
    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/d/optout.
  • Davide D'Agostino at Jul 14, 2014 at 8:05 pm
    Thanks Andrew,

    I totally understand, sorry for the confusion between dev/nuts and multiple
    posts but I got "permissions errors".

    Thanks again for all your advices and I'll try to follow better them all.

    Very appreciated
    Cheers
    DD
    On Sunday, July 13, 2014 4:37:40 PM UTC-7, andrewc...@gmail.com wrote:

    I'm guilty of this too, but I've realized we should really keep these
    types of proposals to golang-nuts (I see you have posted there too) at
    least until the idea has been discussed more and maybe had a highly
    positive response by a majority of people.

    There are a few reasons:

    1. The official language isn't going to change at all for a while, so no
    proposal like this requires any code work. Therefore it doesn't really need
    to be on the dev list.
    2. This proposal in particular isn't really fully formed, I can see a few
    problems, so even if it's a good idea, won't require any dev work yet..
    3. The decision makers do actually read golang-nuts even if they don't
    always reply. You can rest assured a good idea won't go totally unread.

    Not trying to dismiss your ideas. It's just the other proposals from that
    are currently active on the dev list are fairly extensive and well
    specified, are tooling changes and not language changes and are coming from
    people who directly influence and control the official Go specs.

    On Monday, July 14, 2014 5:32:12 AM UTC+12, Davide D'Agostino wrote:

    Hi All,

    we all know that one complain about go is the lack of *generics*.

    However in `real life`, we don't miss them so often.

    There are still cases we all like to have some kind of `generic` type.

    To partially solve this problem we workaround using interfaces{} as input
    parameters with type assertions, or we wrap a interface around a custom
    type.

    So I came up with a simple idea: *type family*

    Type family should respect two laws:

    1. Can't be allocated
    2. Acts as real type

    Basically given a *type family*:

    type Unit (byte, rune)

    type Units (
    []Unit,
    string
    )


    Can be read as:

    Unit is a *type *(family) that can be: *byte *or *rune*
    Units is a *type *(family) that can be: *[]Unit* or *String*

    In this way we can build a `generic function` like:

    func insertAt(s Units, c Unit, i int) Units {
    s = append(s, 0)
    copy(s[i+1:], s[i:])
    s[i] = c
    return s
    }

    This reads as: Insert is a function that accepts a source *s *of type *Units,
    *a *c *of type *Unit *and returns (the modified s): *Units.*

    We can use this function in a pseudo generic way as:

    a := "Hello World"
    b := []byte(a)
    c := []rune(a)

    insertAt(a, "a", 10)
    insertAt(b, '!', 10)
    insertAt(c, '!', 10)

    I think this is very easy to implement, we just need to update the
    grammar and the parser to type check the family with an *OR* condition.
    Without losing the precious type check of the compiler.

    The solution keeps go-lang still very clean and simple and doesn't affect
    the current code.

    What do you think?

    Cheers,
    DAddYE
    --
    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/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedJul 13, '14 at 8:01p
activeJul 14, '14 at 8:05p
posts3
users2
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase