What would you need those for? For checking exhaustive type switches? Seems like an extra keyword on "interface" would do the trick.
Is this comment meant for this article? I can't for the life of me grok what you mean!
What I'd like to see in Go 2.0
121–130 of 223 posts
Re: What I'd like to see in Go 2.0
#122About the optimization of the regex package: a talk is scheduled tomorrow [0] to FOSDEM 2022.
[0] https://fosdem.org/2022/schedule/event/go_finite_automata/
Re: What I'd like to see in Go 2.0
#123Earlier quoted context omitted.
> but (deterministic-select cases) hey are peculiar. It looks for most select blocks in Go code, it doesn't matter whether or not they are non-deterministic or deterministic. But, if the default is deterministic, user code could simulate non-deterministic, without much performance loss. Not vice versa (the current design).
> Not vice versa (the current design). select { case: chan3_whichItreatTheSameAsChan2 }
Yes, as I have mentioned, there is performance loss, comparing to
select {
case: chan3_whichItreatTheSameAsChan2
}Re: What I'd like to see in Go 2.0
#124What would you need those for? For checking exhaustive type switches? Seems like an extra keyword on "interface" would do the trick.
Is this comment meant for this article? I can't for the life of me grok what you mean!
Guessing it was meant to go on https://news.ycombinator.com/item?id=30205232 ? No idea how it ended up here
Re: What I'd like to see in Go 2.0
#125To expand on the logging improvements, I would like to see a `context.WithLogger` context function, to allow cross package passing of a common logger instance.
Re: What I'd like to see in Go 2.0
#126Earlier quoted context omitted.
> Really not sure what you're talking about. Have you considered reading?
Have you considered elaborating? I am likewise unsure how a language could get enums wrong, even after reading your post.
> I am likewise unsure how a language could get enums wrong, even after reading your post.
By allowing any value of the underlying type, even if they were not values of the enum. The language most famous for this is obviously C:
enum foo { A, B, C };
int main() {
enum foo x = A;
printf("%d\n", x);
enum foo y = 42;
printf("%d\n", y);
}
Now you might argue that this is C so obviously it fucks this up, however that C does this leads to further issues:
- For compatibility with C, C# enums have the same property. I don't know about you, but that surprised me a great deal since Java has type-safe enums (even if they're not sum types).
- Even more so, C++ added `enum class` in C++11, and obviously has inherited C's enums, but enum class still is not type safe, afaik the differences are that `enum class` is scoped (so in the snippet above you'd need `foo::A`) and it's not implicitly convertible with the underlying type. But it's still explicitly convertible (via a cast or list initialisation), meaning you can't assume a caller will remain within the enum.
Re: What I'd like to see in Go 2.0
#127Re: What I'd like to see in Go 2.0
#128Earlier quoted context omitted.
Personally I’ve run into more problems with strict enum types in distributed systems in a team setting, than I have with Go’s lack of them. In that setting, strict enums are usually over-strict and eventually you back yourself into a corner in terms of being able to roll out new enum values. When there’s no clear winner in terms of tradeoffs, I prefer to leave it out of the language like Go has done.
That's a fair concern: if everything is strict, then there's no option to incrementally roll out a new value. Maybe a proper enum type could always have an `Unknown` value, which would allow for the leniency while still forcing the use to think about (and handle) it at compile time?
Oooor the language can have proper type-safe enumerated types of some sort, and if you're in a domain where that's an issue you don't use them.
Re: What I'd like to see in Go 2.0
#129Earlier quoted context omitted.
> but (deterministic-select cases) hey are peculiar. It looks for most select blocks in Go code, it doesn't matter whether or not they are non-deterministic or deterministic. But, if the default is deterministic, user code could simulate non-deterministic, without much performance loss. Not vice versa (the current design).
> user code could simulate non-deterministic I'm curious how? > Not vice versa There are pretty common patterns for this. At least for real word cases where you might have one special channel that you always want to check. Ugly, but in relation to the previous question, I don't see how one is doable and one isn't?
> > user code could simulate non-deterministic
> I'm curious how?
if rand.Intn(2) == 0 {
select {
case: chan3_whichItreatTheSameAsChan2
}
} else {
select {
case: 0xFF ->chan3_whichItreatTheSameAsChan2 // a higher priority
case: Re: What I'd like to see in Go 2.0
#130Earlier quoted context omitted.
The "trap" of the snippet is that `cp` is an array of pointers . What it shows is that Go doesn't have a `value` per iteration, it has a single `value` for the entire loop which it updates for each iteration. This means if you store a pointer to that , you're going to store a pointer to the loop variable which gets updated, and thus at the end of the loop you'll have stored a bunch of pointers to the last item. This…
This has suprised me twice, once in my own code where i ended up ot really understand the problem but just mutated the code till it worked and then later when I was helping someone with their code and the way they structured the question made the still suprising answer memorable. A fix wouldn't be unwelcome but it seems it would have a good chance to cause performance regression - a lot more allocated values maybe on…
> A fix wouldn't be unwelcome but it seems it would have a good chance to cause performance regression - a lot more allocated values maybe on a lot of inner loops. I guess escape analysis might help avoid the allovations in the general case. ?
It seems unlikely unless the code is already incorrect (aka you're closing over or otherwise leaking the iteration variable).
But regardless of how I dislike the current loop's scoping this is a significant semantics change so it would obviously have to be opt-in (and it would hopefully come alongside making range loops less crummy e.g. with an actual iterator interface).