101–110 of 219 posts
This: "(b Box[T]) Map[U any](f func(T) U) Box[U]" is the type of cognitive weight I was happy that Go avoided.
> interfaces still can’t declare type-parameterized methods What would an implementation look like? Wouldn't it be quite different from the existing one because it has to rely heavily on indirection because (limited) monomorphimization is not possible?
Earlier quoted context omitted.
I never understood the convention of using single letter names for generic parameters. I guess this started in C++ and every language has copied that convention. I think that code would be a lot easier to read if the types were called IN and OUT or In and Out or TIn and TOut or something like that.
Swift generics tend to idiomatically use longer names, like Element or View or Content.
This level of generics actually has me interested a bit in Go now.
Can generics be used to improve error handling and eliminate the if err pattern?
No. I kind of want to leave it there. But that will probably be looked on disfavorably. I've seen at least a dozen attempts. It's not like it's hard to write it out. There's maybe a couple of variants but they're all just a handful of lines. The problem is, once you have an Option in hand, you end up trading: val, err := whatever(...) if err != nil { // handle error } // use val for val := whatever(...) if err, isErr…
There’s also convenience at the returning side. You can always just return the error, and not have to care about dummy values for the other return values (which is especially annoying when changing the returned types).
That said, it might still not be worth the added complexity.
Earlier quoted context omitted.
No. I kind of want to leave it there. But that will probably be looked on disfavorably. I've seen at least a dozen attempts. It's not like it's hard to write it out. There's maybe a couple of variants but they're all just a handful of lines. The problem is, once you have an Option in hand, you end up trading: val, err := whatever(...) if err != nil { // handle error } // use val for val := whatever(...) if err, isErr…
I think my opinion will be even more maligned: I like Java-style checked exceptions. It forces awareness of the error and a clean way to propagate it.
>The quieter but bigger change I really wish they didn't use such stupid LLM-isms.
I do wonder whether, as a group of people being regularly exposed to text written by LLMs, we'll gradually end up writing and talking like that in our normal language. At that point perhaps text written by LLM and human will be indistinguishable. I already find myself using terms like 'footgun' in jest more than I ever did before! "The creatures outside looked from pig to man, and from man to pig, and from pig to man…
>func (b Box[T]) Map[U any](f func(T) U) Box[U] {} That's completely unreadable.