Quoting Andy Balholm (2018-11-03 16:40:39)
> But if a mis-matched type was passed to Less, it would need to panic.
> So this option (using the Self type) would somewhat reduce
> compile-time type safety.
This is why I left `self` out of my own proposal; while I agree it would
be more ergonomic, it wasn't immediately obvious what to do about this.
I think doing a run-time check is more of a footgun than is justified by
what is gained.
>From a type-theoretic perspective, it's not hard to actually enforce the
`self` constraint statically, even in the case where the code is really
using an interface value, not just a type parameter whose bounds are
specified by an interface. But from a user's perspective it gets weird,
because then if you have:
var s []Lesser = ...
You can't actually do s[i].Less(s[i+1]), because their 'self' types might
not be the same.
I don't like exposing this fairly general mechanism for one ergonomic
improvement, esp. if we don't have any deeper use cases for actually
being able to say `self` -- it seems like we'd be trading a decent chunk
of cognitive overhead for a couple keystrokes.
You could potentially do more compelling things with methods that return
`self`, since then you can actually get more than one value of the
`self` type. But my own inclination is to keep things simple.
-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.
