I have the similar thought as the thread. In terms of a contract, it is
mainly to express these:
1. Methods set: this could be easily expressed by interface
2. Operators set: In go, we could not add or remove the existing
operator set for a given type, which is completely inherited from its
underlying type. So it is equivalent to explicitly express operation set vs
to express the union of underlying types.
3. Type conversion:
1. conversion between types with the same underlying type
2. conversion between numeric types
3. conversion from concrete types to interface
So it is obviously that what we are lacking is: expressing underlying types
and expressing the combination of them, i.e. union type. So maybe a
contract could be written like this:
contract Foo(T) {
int(T) || float64(T) || complex128(T) // underlying type: int, float64,
complex128
InterfaceA(T) // at the same time, it
should satisfy InterfaceA
}
contract Slice(S) {
[]T(S) && Foo(T) // S is a slice, and retrieve the element type to T,
and T should match contract Foo
}
contract Map(M) {
(map[K]V)(M) && Foo(V) // M is a map, whose value type match contract
Foo.
}
There is still no way to express that a type should have a field "f" - But
maybe we can accept this?
In this case, contract is more orthogonal to the existing concepts in go -
we already have the way to express the method set of a type (interface), it
is no needed to be able to express it in contract again.
On Monday, September 17, 2018 at 4:54:04 PM UTC-7, alanfo wrote:
> Thanks for your comment, Patrick.
>
> Although I've relied on compiler magic for my previous proposals, I
> believe we should keep it to a minimum if we can, The 'union' and 'except'
> idea would allow us to compose any group of types we want from the basic
> built-ins and, even within the standard library, it would always be clear
> from looking at the underlying code exactly what those groups comprised.
>
> For me that would be a valuable feature and would still be significantly
> less complex than the draft generics design where every operator used has
> to be spelled out. Under this proposal, the allowable operators/conversions
> etc. are implicit from the types used.
>
> Alan
>
> On Monday, September 17, 2018 at 8:16:38 PM UTC+1, Patrick Smith wrote:
>>
>> I think your idea of creating standard contracts to represent similar
>> types is a good one. However, you don't have to say how those contracts are
>> written, just what they do. No need for typecheck, union, except, etc. For
>> example,
>>
>> Integer(T) - T is an integer type
>> Float(T) - T is a floating point type
>> Complex(T) - T is a complex type
>>
>> For contracts in the standard library, we can just invoke "compiler
>> magic" to explain how they work. Trying to explain the mechanism merely
>> adds complexity.
>>
>
--
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.
