On Sat, Sep 8, 2018 at 6:29 AM, alanfo <alan.f...@gmail.com> wrote:
>
> As it's clear now that Ian wants to stick with 'full-blooded' contracts if
> it can be made to work, I've been trying to think of ways to make them
> easier to work with and to solve some of the issues they currently have.
>
> Reading through the draft for the umpteenth time, one point that
> particularly struck me was that expressions such as:
>
> 1. ' t == t ' implies that both == and != are valid operations i.e. type is
> comparable.
>
> 2 ' t * t ' implies both * and *= are valid.
>
> 3. ' t < t ' implies that <, >, <=, >= , == and != are all valid i.e. type
> is ordered.
>
> Suppose this idea were taken to its logical conclusion.
I want to say that In my opinion we should not take this to its
logical conclusion. Quite the contrary, I think we should have the
absolute minimum of these kinds of inferences. I'm completely open to
removing the ones you list above.
> Now let's further suppose that the standard library contained a contracts
> package (with a nice short name such as 'ct') containing contracts for each
> of these expressions. Let's give them some shortish names such as (in the
> same order):
>
> Eq, Num, Ord, Int, Uns, Sgnd, Float, Cmplx, Bool, Str, Bytes, Runes, Add
>
> So, for the first one, the actual code would be:
>
> contract Eq(t T) {
> t == t
> }
>
> Of course, as the code is not going to be executed, all that matters is that
> these expressions survive the type checker for the actual type used.
>
> The advantage of doing something like this is that where you only need a
> single type parameter and are happy to constrain it to one of these
> 'type-classes', you could do so straight 'out of the box' with a contract
> such as ct.Int, ct.Str or whatever. I suspect that this would cover a large
> percentage of use cases in practice and so would be a worthwhile feature.
>
> It might also satisfy those of us who favored a 'type-class' based solution,
> particularly as it doesn't require any more built-ins or other syntactic
> overhead compared to the original proposal.
I agree that we should do this, for the reasons you state.
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
