A Proposal for Adding Generics to Go

Post by a1369209993 » Tue, Jan 12, 2021, 11:44 PM UTC

RHSeeger wrote: post #66

joshlemer wrote: post #62

Earlier quoted context omitted.

I thought the idomatic approach was to represent sets with map[key]bool

As someone who finds "indicating intent in the code" an important thing, I must admit I find this concert slightly horrifying. A Map and a Set are two different things and which one you use conveys some intent as to what you mean by your code. I get that it works, but it would still make me unhappy to do.

Post by swirepe » Tue, Jan 12, 2021, 11:56 PM UTC

Smaug123 wrote: post #180

uncledave wrote: post #166

Earlier quoted context omitted.

Yeah that's ok until you have 20 million lines of generic ridden crapola pumped out by the lowest bidder. That's the hell I spent a good chunk of the last few years untangling on the C# front. Let's model this correctly! Oh no someone said fuck it, lets just use a bunch of generic data types! Dictionary >>, SortedSet >>> Several thousand out of bounds, missing keys, null reference exceptions, hash collisions and the…

`Dictionary >>, SortedSet >>>` This is not a problem with generics, but with C#'s lack of discriminated unions and/or tiny-types. Except what on earth are you doing with a dictionary whose keys are lists of dictionaries? I am quite sure someone has not modelled their domain correctly there. That's not something you can blame on the existence of generics - I shudder to imagine how much worse it could have been without…

Post by EdwardDiego » Wed, Jan 13, 2021, 12:54 AM UTC

jjtheblunt wrote: post #55

egeozcan wrote: post #16

Earlier quoted context omitted.

I actually just need generic Sets. Generic map/reduce on slices wouldn't hurt too. OTOH, it's 2021 and look at what we are wishing. My love/hate relationship with golang is like the one I have with Apple.

isn't generic Sets easily implemented with map being already generic?

Post by EdwardDiego » Wed, Jan 13, 2021, 1:11 AM UTC

erik_seaberg wrote: post #221

coddle-hark wrote: post #191

Earlier quoted context omitted.

I think map[T]bool is already a pretty good set; the only things you can do with sets are insertion, deletion, iteration and checking for existence and they're all well-supported. Of course, if you need a concurrent set you're right back in type system hell.

You can’t write intersection, union, difference, subset (contains all), or powerset as reusable functions for any element type. The idiomatic thing for now is to rewrite them as loops over and over, but that’s error prone, hard to read, and not a good use of time.

Post by a1369209993 » Wed, Jan 13, 2021, 1:21 AM UTC

hackyhacky wrote: post #33

DaiPlusPlus wrote: post #30

Earlier quoted context omitted.

C doesn’t lack safety by-design - it’s hobbled by its history and constraints imposed by its userbase - otherwise C would have major breaking changes more often.

C absolutely lacks type-safety by design. Otherwise what would malloc return, besides void*? How would you implement generic containers in C, without using macros or void*? Edit: formatting

  #define NULL ((noreturn*)0)
  noreturn* malloc(size_t);
  void free(void*);
  noreturn exit(int); // never returns
  int main() {
    // where (T)... is any expression of type T
    void x = (T)...; // throw away the value
    T y = (noreturn)...; // a nonterminating expression
    void* p = (T*)...; // pointers convertible *to* void*
    T* q = (noreturn*)...; // pointers convertible *from* noreturn*
    *(noreturn*)...; // notionally, this should always fault
    *(void*)...; // read zero bytes, so always fine
    }