tapirl

17 ms·

211.
by tapirl 3y ago
The proposal has two parts, one is to change the semantic of "for-range" loops, the other is to change the semantic of traditional c-like "for;;" loops. The first part is good and will fix your problem. However the secon
212.
by tapirl 3y ago
Many people think the change is only applied to "for-range" loops. However, in fact it will be also applied to traditional c-like "for ;;" loops, which at least will produce two surprises to old Go programmers: https:&#
213.
by tapirl 3y ago
Not exactly. C# had never gone through the change on c-like for-loops.
214.
by tapirl 3y ago
Please note that, the Go proposal is for both "for-range" loops and traditional "for;;" c-like loops. I think it is okay to make the change for "for-range" loops, but not okay for traditional "for;;"
215.
by tapirl 3y ago
The change for "for-range" loops generally has positive effects (except that it will hurt performance sometimes). But the change for "for;;" loops has many bad effects.
216.
by tapirl 3y ago
Not exactly. I'm fan of the change for "for-range" loops, but not a fan for the change for "for;;" loops.
217.
by tapirl 3y ago
In short, the new proposed Go semantics automatically declared an inside variable which has the same name as the iteration variable "I". So the inside "I" is not the iteration variable "I".
218.
by tapirl 3y ago
Sorry, it looks the HN backend edited the title automatically. The condition should be "p != &I". (BTW, the HN backend also auto changed all "i" to "I").
219.
by tapirl 3y ago
I don't misunderstand it. I know the facts in C#. But the Go proposal is different. The proposed change is for both "for;;" loops and "for-range" loops.
220.
Since Go 1.22, loop {for I, p:= 0, new(int); p = &I; {p = &I}} might never exit(old.reddit.com)
26 points by tapirl 3y ago|17 comments
221.
by tapirl 4y ago
Isn't it like putting your local repository on a dropbox or onedriver managed directory?
222.
by tapirl 4y ago
It is really a pity Go didn't support the comparable interface from 1.0. The Go 1.20 change is just a compromise between theory perfection and the pity.
223.
by tapirl 4y ago
It does set the seed value like previous. The docs says calling Seed(1) forces the old behavior. https://pkg.go.dev/math/rand#Seed
224.
by tapirl 4y ago
The comparison code in the "Goal #2: Handle panics gracefully" section is unconvinced.
225.
Go Built-In Slice Manipulations Are Incomplete(go101.org)
2 points by tapirl 4y ago|0 comments
226.
by tapirl 4y ago
Loop back: you can use the panic/recover way. > ... that's bad design. This is a subjective opinion. Many people don't think so.
227.
by tapirl 4y ago
Many others have contrary opinions. So this is just a subjective preference. If you like using exceptions, just don't choose Go. It is useless to criticize it. Go will not change for the criticism, and it is unable to change at this ti
228.
by tapirl 4y ago
Yes, panics are not totally the same as exceptions. You can view them as simpler and less powerful exceptions. The Go culture is almost different from Java form every perspective. Go prefers explicit errors over exceptions.
229.
by tapirl 4y ago
Go supports exceptions: panics.
230.
by tapirl 4y ago
What is the way you recommend?
231.
by tapirl 4y ago
In my honest opinion, you describe a theory problem not happening in production practice. It is the NORMAL behavior to let it panic when a nil receiver is dereferenced. DON'T try to check it!
232.
by tapirl 4y ago
The author doesn't use Go any more, but cares about Go so much. ;D
233.
by tapirl 4y ago
> panics are easy to trigger (e.g. methods with nil receivers) No, methods nil receivers in Go don't trigger panics (if they are not dereferenced). > every error must be handled explicitly, and every control flow path must be mad
234.
The docs of Go 1.20's arenas experiment feature(twitter.com)
1 points by tapirl 4y ago|0 comments
235.
by tapirl 4y ago
Great except that it is no-JS unfriendly. At least the page should be view-able instead of a blank when JS is off. [update]: It is prone to mis-click on a link in the editing mode.
236.
AConstStr[I] in Go is not a constant, it is a pity and it is a luck(go101.org)
1 points by tapirl 4y ago|0 comments
237.
by tapirl 4y ago
Yes, for most cases, the for-loop is as efficient as the proposed "clear" function. I am not sure whether or not this is still true if there are NaN keys in the cleared map.
238.
by tapirl 4y ago
overall balance and flexibility: https://github.com/go101/go101/wiki/The-main-sell-point-of-G...
239.
by tapirl 4y ago
I maintain Go 101 books. Here are some articles highlighted by me: https://twitter.com/go100and1/status/1589549426988969986
240.
by tapirl 4y ago
Feasible only if md is a totally specified format.

More ›