>
> FWIW, I think Ian's criticism of not wanting a list of new identifiers to
> express operator constraints is fair. It is a genuine roadblock to c) and
> if we're dead set of setting that as a baseline requirement, I agree that a
> declarative/interface-based approach won't work.
>
I don't understand. Why are names so important? Why couldn't you use "T ==
T" to mean "T is comparable"? Or "To(From)" to mean "From is convertible to
To"?
> Personally, I don't think that should be a requirement. Personally I think
> it's worth adding extra identifiers, if we get declarative constraint-specs
> for that - but that's just my opinion and everyone has one of those.
>
> But the issues you are bringing up are IMO not "fundamental'. a) to c)
> from above aren't really touched by your criticism, AIUI. To me, they seem
> like issues of syntax and how to phrase the spec.
>
> But if generics are to have operator constraints like T == T, then
>> something in the language has to change. Either not all interfaces are
>> types, or some interfaces have methods that can't be called, or Go
>> operators can have operands of different types. These changes are not minor
>> tweaks: they alter fundamental aspects of the language.
>>
>> Contracts, on the other hand, are purely additive. They only come into
>> play when writing generic code. If I'm not mistaken, the draft design
>> doesn't change or even add anything to non-generic Go. There is something
>> attractive about that orthogonality.
>>
>
> I agree. I think that's fair. I don't think for that they need to be
> imperative specifications though.
>
> (or, allow embedding interfaces into contract-declarations, remove the
>>> "type-checking function body" idea and instead define a set of
>>> base-contracts you can use for operators) and you'd end up with pretty much
>>> my design.
>>>
>>
>> That doesn't sound like your original design at all.
>>
>
> You need to squint harder :) From the rest of your mail, ISTM that we are
> putting emphasis on different aspects of my description and the contracts
> design. What I was trying to say is that IMO the things about my design I
> like and the things about the contract design you like can probably be
> reconciled.
>
> The first seems problematic, because for multi-parameter contracts you
>> wouldn't know which type the parameter referred to.
>>
>
> FWIW (we are now getting lost in ifs-and-buts and it's no longer clear
> what the specific ideas are we are talking about), in my original design as
> well as that ad-how handwaving you're quoting, constraints always apply to
> a single type and you'd use parametric interfaces (or… interfaces+) to
> express simultaneous restrictions.
>
> But FTR, I did not intend to start an actual discussion around that, its
> far too underspecified for that. I was sincere when I said your criticism
> is fair and that I had to think about it. My handwaving was just to explain
> why I don't think it can justifiable be called a *fundamental* issue.
>
>
>> The second seems reasonable to me. Now we can talk about issues like
>> whether this adds too many names to the language, or whether you've
>> described all the important constraints (I think conversion and
>> assignability are important, for instance).
>>
>
> Again, the caveat of handwaving still applies (IMO we should constrain
> ourselves to talk about sufficiently spelled out designs - Ian's contract
> design qualifies and I'd also feel fine with the thing I wrote down in my
> blog, as long as we agree that its conditional on polishing the "are
> pseudo-interfaces usable as types" question), but: Given that we have
> type-parameters, adding that is fairly straightforward in the form of (in
> the words of my blog post) parametric pseudo-interfaces
> "convertible{To,From}(T)" and "assignable{To,From}(T)".
>
> But yeah, talking about in too much depth here would IMO constitute
> high-jacking of threads about Ian's design. I'm also totally cool to start
> a new thread about this after I had time to incorporate your feedback.
> Unfortunately this isn't my job, so I have to find time between other
> things :)
>
> Anyway. I think I've been ranty enough for today :)
>
> On Sunday, September 9, 2018 at 5:21:28 PM UTC-4, Axel Wagner wrote:
>>>
>>> I don't think saying that is is productive. contracts are more than just
>>> "identifiers used as constraints", they are also a syntactic construct to
>>> specify those. I specifically don't allow that and that's the whole point
>>> I'm making. So this doesn't seem like a particularly nice way to have a
>>> discussion.
>>>
>>> But yes, if it makes you happier, we can call them "contracts", allow to
>>> embed them into interfaces and remove contract declarations from the design
>>> (or, allow embedding interfaces into contract-declarations, remove the
>>> "type-checking function body" idea and instead define a set of
>>> base-contracts you can use for operators) and you'd end up with pretty much
>>> my design.
>>>
>>> On Sun, Sep 9, 2018 at 11:17 PM Jonathan Amsterdam <jbams...@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sunday, September 9, 2018 at 3:19:16 PM UTC-4, Axel Wagner wrote:
>>>>>
>>>>> On Sun, Sep 9, 2018 at 8:49 PM Jonathan Amsterdam <jbams...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> The problem is that this program seems to type-check, but it is
>>>>>> invalid. The == operator is specified to work on operands of the same
>>>>>> type,
>>>>>> and it is being used on operands of different types.
>>>>>>
>>>>>
>>>>> Good point. I have to think about it. An ad-hoc solution, FWIW, would
>>>>> be to only take into account (or allow) pseudo-interfaces for
>>>>> type-constraints.
>>>>>
>>>>
>>>> The draft design has a name for those: contracts.
>>>>
>>>> --
>>>> 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...@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.
