On 4 September 2018 at 17:30, Tristan Colgate <[email protected]> wrote:
> This would disallow contracts on presence and type of fields right?
> The existing design permits them, and disallowing them feels a little
> arbitrary.
It would, yes. But on balance, I think that the presence of selectors
in contracts makes for them harder to understand. For example, the
rather arbitrary rules about value methods go away if you don't allow
selectors. The ambiguity between a field selector and a method
selector goes away too. For example, the Stringer contract in the
design doc purports to check that there's a method named String, which
it does not - it could be a function-valued field instead.
So if you've written something like this:
func FastString(type T stringer)(x T) string {
switch x.(type) {
case myType:
return x.String()
default:
// Slow path: fall back to fmt.
return fmt.Sprint(x)
}
}
you might expect that fmt.Sprint will call the String method that's
defined on x, but that's not guaranteed.
The selector operation does so much work in Go that it's hard to
classify it as a single operation, and I think that disallowing it
lets values focus more on behaviour and less on appearance, as
interfaces do.
>
> On Tue, 4 Sep 2018, 17:17 roger peppe, <[email protected]> wrote:
>>
>> On 4 September 2018 at 15:41, thwd <[email protected]> wrote:
>> > From the draft proposal I gather two open questions:
>> > - How free or restricted should contract bodies be?
>> > - How many implicit constraints can be inferred from usage?
>> >
>> > If too much syntax is allowed in contract bodies and no implicit
>> > constraints
>> > are gathered:
>> > people will copy and paste function bodies into contracts to cover all
>> > constraints.
>> >
>> > If only restricted syntax is allowed in contract bodies and a lot of
>> > implicit constraints are gathered:
>> > people will write empty contracts and hope for the compiler to pick up
>> > on
>> > all the constraints.
>> >
>> > These two questions are related.
>>
>> As I understand it, if a contract doesn't allow it, you won't be able to
>> do it.
>> That is, the contract is scanned for "operations" (however they might be
>> defined), and then it will be a compiler error if a function uses an
>> operation
>> not permitted in the contract.
>>
>> An empty contract body permits no operations other than those available
>> on every Go value (copying, taking address of, passing as a parameter,
>> etc).
>>
>> So I'm not entirely sure what you mean by "implicit constraints".
>>
>> That said, it is my opinion that it is very hard to read an arbitrary
>> constraint
>> body and infer the set of possible operations that can be performed.
>> It's not that much easier to look at it and work out what types might
>> satisfy
>> the contract either.
>>
>> My suggestion (that I've written up here:
>> https://gist.github.com/rogpeppe/45f5a7578507989ec4ba5ac639ae2c69) is
>> that, at least to start with, we allow only a very restricted set of
>> contract bodies.
>>
>> Specifically, in my suggestion, every statement in a contract body
>> must consist of exactly one expression.
>> Identifiers in the expression can only reference types or the
>> contract's parameters.
>> The expression must reference at least one of the contract's type
>> parameters.
>> The expression must exactly one of:
>> - any unary or binary operator (but not a field or method selector)
>> - a function invocation
>> - a type conversion
>> - an index expression
>>
>> Intuitively I'd like a single statement in the expression to specify
>> exactly a single operation which should be clear from the operands of
>> the expression.
>>
>> Thus if you look down the contract and you don't see the operation
>> you're looking for, then you can't do it.
>>
>> cheers,
>> rog.
>>
>> --
>> 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 [email protected].
>> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
