On Wed, 12 Sep 2018 07:05:55 -0700
Ian Lance Taylor <i...@golang.org> wrote:
> I don't see a description of generic types, I only see generic functions.
CGG in its current shape does not allow for **declaring** generic named types
out of thin air. But it allows for instantiating such types
(now p 3.2 in draft):
// likely to be seen in generic package
func NewBarTuple(type T, type V) ( r type R ) {
var r = struct { a T; b V }
return
}
I am open to suggestions
> I don't understand how you handle a named type like `type MyInt int`.
MyInt in the contract scope "is assignable" to int via int(MyInt);
thats why the constraint is written **as a cast** [ T = TypeX() constraint ].
type MyInt int
var a MyInt
var b int
b = int(a)
> Such a type is neither identical to `int` nor assignable to `int`.
But if the base agrees it can be casted to. Hence "assignable to type()"
> You don't have a way of saying "convertible to `int`", and if you did
> it's not clear how it would handle, say, `float64`.
And I will likely not have "convertible to" because it needs from the reader
knowledge about peculiarities of any given conversion.
I am open to suggestions. Readability first.
(In fact I had convertible in my first sketch but I removed it
exactly because of float/int snafu memories)
The `for type` contract allows me to specify a method, so explicit function
like "ConvertTo" or "GetAs" are better **for reader**.
Constraint list is not closed. Only restriction on this list is that a
constrain (as for now) must be expressed as **known** Go
construct involving a type or part of it (ie field). No operators or code.
>
> Ian
TC,
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE
--
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.
