Correction: you'd only need 3 additional built-ins as 'real' is already
used to find the real part of a complex number.
Although it would be used differently here, you might want to use 'numeric'
instead to avoid confusion.
Alan
On Tuesday, September 11, 2018 at 11:31:03 PM UTC+1, alanfo wrote:
>
> 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 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.
>> 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.
