(I'm acutely aware that there's a limit to how useful endless back and
forth on this stuff is, and I definitely have to yield on the technical
details here, I'll leave the grown up to discuss after this I promise)
On Tue, 11 Sep 2018 at 14:26 Axel Wagner <axel.wagner...@googlemail.com>
wrote:
> There is no accounting for taste, of course, but I wildly disagree. In
> particular, the constraint solver and type-checker for what I described is
> trivial to write and understand, including good error messages. AIUI it is
> currently not clear whether the contract design can actually be
> type-checked in practice (and, personally, I am predicting the things I and
> others are bringing up to be exactly the things that will come up as
> difficultlies).
>
I guess if I were going to critique this I would say that optimising for
ease of compiler implementation may not be the best thing. *If* the
existing design can be made to work (and that's clearly a big "if"), then I
think I would still find it preferable, as you say, no accounting for taste.
Having a package of pre-defined contracts, and a tool and that can produce,
and reduce contracts, if possible, would simplify things.
To be completely honest, I think I'd be happy with your design if it just
stopped before "Getting rid o boilerplate", I'd rather just live with the
boilerplate than introduce the taxonomy that comes after. Also, personally,
I'd rather leave interfaces alone and have the typed interfaces be a
separate thing, but I don't understand this well enough to know if that
really works.
func Foo(w io.Writer) { fmt.Fprintln(w, "Hello world") }
> func main() { Foo(os.Stdout) }
>
> The compiler could decide to devirtualize the interface, to generate a
> boxed version or to do a hybrid approach (e.g. compile a boxed version and
> devirtualize for certain types based on usage). Exactly like with the
> contract designs.
>
It could, but this would change how people currently understand interfaces
to work, e.g. in regard to nil-ness of interface values. This is already a
bit of a hurdle for beginners.
> I still believe that if there's a simpler alternative (and I consider my
> design simpler, for the implementation, the author and the user of generic
> code. But I'm obviously biased) that creates higher levels of type-safety,
> while not giving up a significant amount of expressive power, then that
> should be at least considered. Because it's just as much not obvious that
> contracts provide the wrong level of type-safety, as it's obvious that they
> provide the only correct level of type-safety.
>
Things certainly look hopeful.
--
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.
