On Fri, Sep 7, 2018 at 5:28 PM, Rob Pike <[email protected]> wrote:
>
> contract unsigned(v T) {
> // Require T to be an integer type.
> v % 1
> // This is satisfied by any unsigned integer type, but not by a
> signed integer type.
> v = 1<<(unsafe.Sizeof(v) * 8 - 1)
> }
>
> That requires an import, not to mention unsafe, which raises the issue of
> whether a contract must be written in pure Go without imports. I'm not sure,
> but I do think it might be good that it does.
In general I think it can be quite useful to refer to imported names.
For example,
contract Stringable(x T) {
var _ fmt.Stringer = x
}
is a simple and clear way to require a type that provides a String method.
> Even then, saying v%1 is the way to ask for an integer is infelicitous at
> best.
Yes. As I alluded to before, I think it's worth asking: why does it
matter? When is it important to not just express what operations are
required for a type, but also to try to rule out some types?
> To my mind this general area is the least clear part of the contracts
> design: what _is_ a contract?
A contract is a compile-time description of which types are permitted
for a polymorphic function or type.
There are two sides to a contract. I continue to hope and believe
that one side is fairly clear: a contract indicates which type
arguments are acceptable, namely those that permit the contract to
type-check successfully. The other side I agree is less clear: what
operations does a contract permit in the generic code?
Ian
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
