Here's the generics discussion: https://github.com/golang/go/issues/15292
Matt
On Tuesday, April 24, 2018 at 9:06:10 AM UTC-5, Deven You wrote:
>
> I am a newbie on Golang and find go syntax is pretty concise and I like it.
>
> However, the syntax for public API seems a little trouble for me.
>
> Whenever I import a package, say:
> import dwu
>
> I need use a var or function with Capital first letter identifier:
>
> dwu.MyFunction
> dwu.MyVar
>
>
> I wonder since we can not use private lower case started identifier within
> a package, perhaps we can just make a set of rules for how to control
> referencing a package public memeber:
>
> 1. function and var and types directly from primitive type
> we can just use lower case to use them like:
> dwu.myFunction
> dwu.myVar
> dwu.integer
>
> //definition of above
> // dwu.go
> package dwu
>
> funcMyFunction(...)...
> var MyVar :="..."
> type Integer int
>
> Inside the dwu.go we just can not define the same identifiers which only
> differentiate from first letter cases like myFunction, myVar, integer etc.
>
> 2. Struct and interfaces still remain the Captial letters
>
> // dwu.go
> ...
> type Foos truct{
> ...
> }
>
> type Less interface{
> ...
> }
>
> //use dwu
> var afoo Foo=...
> var aless Less= ...
>
> 3. We can enforce the use of upper and lower first letters
>
> type Integer+ int//can only refernce it with dwu.Integer
>
> type Integer- int// can only reference it with dwu.integer
>
> type -Integer int // private identifier within dwu, but must use it as:
> var a Integer = 1
>
>
>
> I think using as many as possible lower case started API is more
> convenient and with the point 3 we still have full control of how we
> reference the public API.
>
> I also find golang with no generic syntax. Maybe this is for the original
> difficulty or complexity of generic. But sometimes, generic is indeed
> useful. A common case is for add() for any numeric types.
>
> I think we can invent different but more simple syntax to achieve the same
> behavior of generic. Here is my little thoughts:
>
> In C++:
>
> template <typename T>
> T add(T first, T second) {
> return first+ second;
> }
>
> In Go:
>
> func add(first as a Addable, second a.type) { // or (first Addable as
> Atype, second Atype)
> var result a.type
> return first + second // or first.add(second) if Go won't support
> operator overload in any future version
> }
>
> We just use a.type or Atype to ensure first and second belong to one
> certain same type which implements the Addable interface.
>
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
