Jonathan,
The problem with just 'OR'ing complex64 and complex128 together is that the
resulting contract wouldn't encompass any defined types with the same
underlying types. So 'mycomplex' wouldn't be included:
type mycomplex complex64
However, I'm pleased you mentioned it as it's given me an idea. Maybe my
'fuller' proposal was on the right lines after all, it just needed
simplifying :)
Suppose (with the sole exception of Comparable) we get rid of the built-ins
altogether and instead add two new assertions to the four that are already
permitted within a contract body:
union{...}(T)
except{...}(T)
These would assert that a type parameter must represent a type within the
'union' body but NOT represent a type within the 'except' body. The
following could go within the body:
1. Any non-generic type.
2. Any contract requiring exactly one type parameter (inferred to be T).
Other rules would be:
3. There could be any number of constituent types/contracts with a minimum
of one.
4. Any type specified under #1 would be deemed to include any defined type
with the same underlying type (IMPORTANT POINT!).
5. Any contract could contain at most one 'union' or 'except' assertion.
6. 'union' and 'except' would only be keywords within this context. Other
uses would be unaffected and so the proposal would still be backwards
compatible with Go 1.
Incidentally, I'm NOT suggesting that we should add union types to the
language itself; these constructs would only apply within a contract body.
It would now be a simple matter to build up a standard contracts package
("ct" say) which included those originally envisaged: Integer, Signed,
Unsigned, Float, Complex, Boolean, String, Real, Numeric, Ordered, Addable,
Bytes and Runes. For example:
contract Signed(T) {
union{ int8, int16, int32, int64, int }(T)
}
contract Unsigned(T) {
union{ uint8, uint16, uint32, uint64, uint, uintptr }(T)
}
contract Float(T) {
union{ float32, float64 }(T)
}
contract Complex(T) {
union{ complex64, complex128 }(T)
}
contract Integer(T) {
union{ ct.Signed, ct.Unsigned }(T)
}
contract Numeric(T) {
union{ ct.Integer, ct.Float, ct.Complex }(T)
}
contract String(T) {
union{ string }(T) // includes any defined type based on string
}
contract Bytes(T) {
union{ string, []byte }(T) // includes defined types based on string
or []byte
}
The Add1K example could now by made to work properly with this contract
which disallows 8 bit integers:
contract BiggerInts(T) {
ct.Integer(T)
except{ int8, uint8 }(T)
}
Incidentally, any one who dislikes having to qualify stuff with "ct" could
get rid of it in the 'import' declaration as long as they were confident
they wouldn't reuse the names of the standard contracts in the current
source file:
import . "ct"
So what do you think of this idea?
It's certainly more expressive than the simplified proposal as it stands
and (apart from stuff like a totally generic Min() function which would
require contract adaptors) I'm struggling to think of anything it couldn't
do that I'd want it to do.
Alan
On Sunday, September 16, 2018 at 11:22:35 PM UTC+1, Jonathan Amsterdam
wrote:
>
>
>
> On Friday, September 14, 2018 at 8:06:31 PM UTC-4, alanfo wrote:
>>
>> Thanks for your comments, Jonathan.
>>
>> I did in fact deal with all the cases you mention in my 'fuller' proposal:
>>
>> https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251
>>
>> where I'd used a device to restrict the built-ins to just one following
>> criticism by Ian that an earlier proposal I'd made had too many of them (it
>> had 14).
>>
>> However, I decided instead to restrict the built-ins to a reasonable
>> number (6) in the simplified proposal which meant that many of them had to
>> go.
>>
>
> Your 'fuller' proposal says that you can "or" the builtins together. But
> if you have that, you can get rid of many of them. For instance, "complex"
> is just "complex64 or complex128".
>
>>
>> The example you mentioned was taken from the draft design paper and
>> didn't compile for int8 there either.
>>
>
> Sorry, I shouldn't have used the word "compile" because it's ambiguous.
> Neither your Add1K nor the draft design's can be instantiated for int8.
> However, the draft design Add1K is valid with respect to its contract.
> Yours isn't, because the contract admits int8 but the function doesn't.
>
--
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.
