Robert,
I suspect that you could achieve 90% coverage with just 4 built-in
contracts:
1. integer (any integer type)
2. real (any integer or floating point type)
3. ordered (any integer, floating point or string type)
4. comparable (any type which supports == and !=)
If you had just one type parameter, a built-in contract could be applied
directly to it where appropriate. For example:
func FormatUnsigned(type T real)(v T) string {
return strconv.FormatUint(uint64(v), 10)
}
Otherwise, you'd need to create a user defined contract whose constituents
could be restricted to the following:
1. Other embedded contracts (including the built-ins)
2. Interface conversions.
This would still allow you to do some quite complicated things. For example:
contract Graph(n Node, e Edge) {
interface {
Edges() []Edge
}(n)
interface() {
Nodes() (Node, Node)
}(e)
}
func ShortestPath(type N, E Graph)(src, dst N) []E { ... }
However, you wouldn't be able to specify that structs contain specific
named fields, that a type parameter must either be a string or a byte slice
and many other things.
>From my own perspective I think I'd be happy with a relatively simple
constraint system such as this but, as I said earlier, I don't think it'll
be enough for the Go team who (within reason) are looking for something
more comprehensive.
Alan
On Tuesday, September 11, 2018 at 5:27:38 PM UTC+1, Robert Engels wrote:
>
> As I’ve said elsewhere, a SIMPLE to use and understand solution that
> covers 90% is better than a complex one to cover 100% IMO, and fits in well
> with the rest of Go design. Go leaves out a lot - intentionally - and it’s
> a good choice.
>
> On Sep 11, 2018, at 11:22 AM, alan...@gmail.com <javascript:> wrote:
>
> There is one thing which I think is quite clear from all the discussions
> that have taken place on this topic.
>
> Having withstood years of criticism for the lack of generics in Go, the
> team are not going to be satisfied now with some under-powered or
> half-baked solution. They want to have as much power as possible within a
> coherent and (hopefully) easy to understand design.
>
> Now, it says in the draft design paper, that they considered using
> interfaces but couldn't find a clear way to represent operators using
> interface methods. Having tried to do that myself, I have a lot of sympathy
> with that position!
>
> So instead they came up with the idea of the type parameter(s) having to
> satisfy a number of requirements which could be expressed in 'normal' code
> and embodied in a new construct called a 'contract'. This idea is somewhat
> similar to 'concepts' in C++ as Ian has already pointed out.
>
> The problem is that many of us don't find the sort of code used in
> contracts (as currently envisaged) to be 'normal' at all and we're worried
> that the Go community at large will find them difficult to write (though a
> tool may help), understand or use. What you've just said, Jeff,enforces
> that view.
>
> So we've put forward some alternative proposals under the feedback system
> to try and address the perceived shortcomings of the present system, though
> it's not easy.
>
> I do however have faith that the Go team will eventually come up with
> something that will be reasonably powerful, understandable and consistent
> with the 'soul' of the language. Let's hope my faith is not misplaced.
>
>
>
> --
> 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...@googlegroups.com <javascript:>.
> 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.
