On Sun, 30 Sep 2018 at 17:56, robert engels <reng...@ix.netcom.com> wrote:
>
> I think you address the first, with a “toUnsigned” method, but I am not sure
> that semantically makes sense for a lot of types except numerics, but
> “shifting” is only supported on numeric types anyway.
>
> I have always thought that not having automatic conversions for numerics in
> Go is a bit strange. I think it makes some code much safer, but it also makes
> a lot of code a PITA and way more difficult to read.
For me the amount of code which is much safer and more clear is much
more than that which is more contorted by explicit casting. When a
language encourages or discourages code style by having rules which
solve some problems and make other ways of expressing more difficult,
there is tendency for people to find other more natural ways of
expressing those later things, so they show up less.
>
> As I’ve said before, I think people are over complicating it, and if Go had
> ‘generic type-safe collections” - possibly even just adding new options to
> ‘make' to say “concurrent” and maybe a few other “OR-able options”, like
> “ordered_keys”, etc and and do it behind the scenes (the runtime picks
> different implementations, and possible allow the developer to register
> others), and then keep the current syntax (for maps, slices, etc.) and just
> about everyone would be happy.
>
> The non-collection cases can readily be solved with interfaces in most cases.
>
Maybe you can write up these ideas, make them concrete enough to think
through and consider w.r.t. other proposals?
I have an intuition that in any event some kind of genuine generic
programming would be good, and I find the contracts idea very
thoroughly considered and the idea of specifying relations over types
by example compelling in general and for Go in particular. Still
working on (better) unifying the relation of contracts to interfaces,
but that's in no way a rejection of the basic ideas in the contracts
draft proposal.
Scott
> On Sep 30, 2018, at 10:32 AM, Scott Cotton <w...@iri-labs.com> wrote:
>
>
>
> On Sunday, 30 September 2018 13:04:55 UTC+2, Robert Engels wrote:
>>
>> The static switch is a big problem. For any complex method you are going to
>> completely duplicate all of the code. Not good.
>>
>> Far better to map operators to interfaces then you only need a single method
>> implementation.
>
>
> I don't think you can easily do that with Go, take for example the constraint
> (according to the draft proposal syntax and semantics)
> contract unsigned(x T) {
> 1 << x
> }
>
> Another problem is pointer dereferencing
>
> contract p(x T) {
> *x
> }
>
> if you define an operator for pointer dereferencing on T by a method, then
> all the rules about what is addressable and dereferencable in Go become very
> complicated, especially w.r.t. interfaces
>
> Finally, all standard languages with operator overloading either
> 1) don't allow you to implement numbers generically for implementations where
> constants for 0, 1, Pi, ... may have different binary representation than the
> constant in the language (such as fixed point numbers); or
> 2) like C++ allow constants to be substituted via templates.
>
> I think some of the literature on "Dependent types" may address this later
> issue, but it's pretty heady stuff and outside the scope of
> what I want to have to think about when coding, so as to focus efforts more
> readily on the objective of the code rather than heady type theory.
>
> practical operator overloading isn't a solved problem AFAIK, much less for Go.
>
> Scott
>
>
>>
>>
>> On Sep 30, 2018, at 5:33 AM, Christian Surlykke <chri...@surlykke.dk> wrote:
>>
>> Hi
>>
>> I made a proposal for generics with constraints about ½ a year ago, which I
>> posted to the (very long) thread on issue 15292. I've now made a version 2,
>> in case anybody would like to read it.
>>
>> This version adapts to the generics syntax now proposed by the Go team and
>> is somewhat simpler than the previous version.
>>
>> br. Chr.
>>
>> --
>> 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...@googlegroups.com.
>> 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 golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
--
Scott Cotton
http://www.iri-labs.com
--
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.
