Thanks for your comments, Jonathan. I did in fact deal with all the cases you mention in my 'fuller' proposal:
https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251 where I'd used a device to restrict the built-ins to just one following criticism by Ian that an earlier proposal I'd made had too many of them (it had 14). However, I decided instead to restrict the built-ins to a reasonable number (6) in the simplified proposal which meant that many of them had to go. The example you mentioned was taken from the draft design paper and didn't compile for int8 there either. ohir has already made the point about overflow being a problem when dealing with integer types and, in practice, you shouldn't write code under any proposal unless you're sure that it will compile for all applicable types. It might help if type assertions could be applied to type parameters so you could test for 'awkward' types. One thing that has been mentioned as a possible new feature in Go 2 is to change the 'int' and 'uint' types from being platform specific (32 or 64 bit) to arbitrary precision (i.e. big.Int). This would then get rid of overflow problems when converting between integer types once and for all. Personally, I hope this happens though I'd prefer 'int' and 'uint' to be left as they are (on efficiency grounds) and introduce a new type - say 'intz' - which would be arbitrary precision. In the circumstances, an unsigned version of this wouldn't be needed. Alan On Friday, September 14, 2018 at 11:24:25 PM UTC+1, Jonathan Amsterdam wrote: > > I'm sympathetic to the general idea, but I don't think this quite does it. > In addition to introducing a bunch of new names, it's not expressive enough: > > - You can't express "string or []byte", as you note. There are many > algorithms where this would be useful. See the strings and bytes packages > for a start. > > - You can't support types that have bool and string as underlying types. > People often define their own string type, usually just for clarity. You > say they can just convert to string, but they can't if they have a > []MyString or the like. It's also confusingly inconsistent to support > underlying types for numbers but not bool or string. > > - Your convert example excludes complex types. You have no way to express > "any numeric type," which is what that example needs. > > - You can't get finer-grained than Integer. That excludes some code. For > instance, your Add1K example doesn't work, because it won't compile if T = > int8. It's not clear how important this is in practice. > > -- 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.
