Thanks for your comment, Patrick. Although I've relied on compiler magic for my previous proposals, I believe we should keep it to a minimum if we can, The 'union' and 'except' idea would allow us to compose any group of types we want from the basic built-ins and, even within the standard library, it would always be clear from looking at the underlying code exactly what those groups comprised.
For me that would be a valuable feature and would still be significantly less complex than the draft generics design where every operator used has to be spelled out. Under this proposal, the allowable operators/conversions etc. are implicit from the types used. Alan On Monday, September 17, 2018 at 8:16:38 PM UTC+1, Patrick Smith wrote: > > I think your idea of creating standard contracts to represent similar > types is a good one. However, you don't have to say how those contracts are > written, just what they do. No need for typecheck, union, except, etc. For > example, > > Integer(T) - T is an integer type > Float(T) - T is a floating point type > Complex(T) - T is a complex type > > For contracts in the standard library, we can just invoke "compiler magic" > to explain how they work. Trying to explain the mechanism merely adds > complexity. > -- 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.
