"Any unsigned number" would allow generic versions of the math/bits
functions, though they'd have to dispatch on unsafe.Sizeof internally,
as a type switch would miss
type Uint uint
But that would presumably be DCE'd if specialized.
Allowing more types than intended isn't always bad. If I have code
that takes a string but I also want it to work on types like
type String string
the contact for that has to be
contract stringy(s T) {
string(s)
len(s)
}
to avoid allowing rune and byte. This is necessary because my code
also has to satisfy the contract. This also accepts []rune and []byte
and that's fine in this case since the code will be using immutable
values. Here it's kind of a nice bonus.
It does seem like writing contracts from scratch will be difficult. If
I want something that works on slice-y things I might attempt:
contract slicey(s T) {
s[0]
}
func rest(type S slicey)(sliceable S) S {
return sliceable[1:]
}
But that will fail to compile because that contract isn't equivalent
to sliceable things: it's equivalent to
for _, _ = range s {}
which is things that can be iterated over that are not channels.
The contract should have been
s[:0]
which is limited to arrays, slices, and strings.
But then the contract accepts [0]T but the code requires at least [1]T
so either the final contract is
s[1:]
or the minimum array size has to be inferred contradicting the premise
of the contract to specify all the constraints on both the acceptable
types and the implementation. The contract could be changed to
make(T, 0)[:0]
which disallow arrays but that also disallows strings.
At that point, it would be simpler to just do
func rest(type T)(slice []T) T {
return slice[1:]
}
While I don't see a way to express that contract, I can see how to
enforce that a struct type has fields A, B, and C in alphabetical
order:
contract superUseful(t T) {
[unsafe.Offsetof(t.C) - unsafe.Offsetof(t.B)]struct{}
[unsafe.Offsetof(t.B) - unsafe.Offsetof(t.A)]struct{}
}
(Assuming the size of each fields is greater than 0; based on
https://twitter.com/lukechampine/status/1013635527801786369 )
No one would write that, except in a "guess what this does!" format, of course.
If there's a contracts package, it would be easier to use contracts.
But my guess then is that a lot of the nonempty contracts in the wild
would match one of these patterns:
contract simple(t T) {
someInterface(t)
}
contract simple2(t T) {
contracts.Comparable(t)
someInterface(t)
}
contract complex(t T) {
contracts.PropertyA(t)
contracts.PropertyB(t)
contracts.PropertyC(t)
contracts.PropertyD(t)
contracts.PropertyE(t)
contracts.PropertyF(t)
}
I get that it avoids introducing those properties directly into the
language but it also locks the language into those properties. You can
never change https://github.com/golang/go/issues/19113 after
introducing contracts because there could be a contract somewhere that
uses 1 << u instead of contracts.Unsigned.
> > struct{ io.Reader; T}{}.Read
>
> Just to make it worse, T would be permitted if T is a struct with an
> embedded field that has a Read method.
That extra level of nesting would still result in the selector Read
being ambiguous causing the contract to reject T.
> It's not clear to me why anybody would write a contract like this.
If you allow embedding a type parameter in a generic struct, you need
that contract to assert that the embedded type parameter does not
conflict with an embedded regular type's selectors or you can't use
them in the methods of the type since they're not always present. You
only need that for selectors you use but any you don't assert like
that can disappear depending on the parameterization so you can have
weird cases where a generic type satisfies an interface unless
instantiated with a type that also satisfies that interface.
On Sat, Sep 8, 2018 at 7:06 AM alanfo <alan.f...@gmail.com> wrote:
>
> OK, fair enough, but the only way you could have a standard package on those
> lines without the compiler doing more inference would be to list expressions
> for every single operator or conversion that the relevant types support. That
> should be doable but I'm not sure whether a particular built-in type (or
> group of such types) would be completely defined in this way or whether it
> would matter if it wasn't.
>
> Anyway, it's an idea to work on.
>
> Alan
>
> --
> 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.
--
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.
