Verbose error handling has its own merits. It is easier to scan,
particularly when you are looking whether you have handled certain cases.
It may be repetitive to write, but it is easy to read and it stands out.
In a language that offers multiple ways to handle an error, you have to
slow down
work.cycles defined as uint32. Assuming gc happens every 2ms, it take
(1 << 32) / 500 / (24 * 3600) = 99 days to overflow. it seems possible.
gcWaitOnMark use (n > work.cycles) test, is this a problem here?
```
// gcWaitOnMark blocks until GC finishes the Nth mark phase. If GC has
//
> My questions: Is any form of loop/invariant-hoisting performed?
Yes, but not much. We hoist simple things like constants and spill
restores. The big kahuna, loads, are typically not lifted because they
depend on memory and we don't have the alias analysis to prove that that is
safe.
We
Dnia 2020-11-11, o godz. 08:01:37
Jeremy French napisał(a):
> I know that's not realistic, and errors are a part of life.
> My point is that they're not the main purpose of the code, and thus shouldn't
> be taking up (up to) 75% of the code space when I'm trying to read what a
> function does.
On Wed, Nov 11, 2020 at 7:42 AM 'Axel Wagner' via golang-nuts
wrote:
>
> https://play.golang.org/p/qTBiAdR9djt
>
> `a` is the address of the first element of `l`.
> `b` is the address of the first element of `l[0]`, which is of type
> `[]interface{}` after the assignment.
>
> Both `l` and `l[0]`
Dnia 2020-11-10, o godz. 19:08:10
"'Kilos' via golang-nuts" napisał(a):
> I just copy the screenshot in this
Do not do that again. It is akin to saying:
"it is more convenient for me to hit two keys instead of selecting text and
paste it what would effect in four strokes for me".
"So now I
On Wed, Nov 11, 2020 at 5:02 PM Jeremy French wrote:
> *shrug* As you said, returnif is still a statement, and yet it reduces the
> minimum boilerplate from 3 lines down to 1.
>
There's a way to get that without a language change - you can have gofmt
make `if err != nil { return … }` into a
On Wednesday, November 11, 2020 at 2:09:19 AM UTC-5
axel.wa...@googlemail.com wrote:
> On Wed, Nov 11, 2020 at 2:43 AM Jeremy French wrote:
>
>> I certainly can't speak for the whole community, but for me, the key word
>> here is verbosity. I don't care (too much) whether it's technically a
BTW, the same idea doesn't work for maps, of course. For maps, you could
exploit the fact that they are pointer-shaped in the current implementation
and use unsafe to compare those pointers:
https://play.golang.org/p/JCeXmoUctT2
You should keep in mind though, that this might break in the future,
https://play.golang.org/p/qTBiAdR9djt
`a` is the address of the first element of `l`.
`b` is the address of the first element of `l[0]`, which is of type
`[]interface{}` after the assignment.
Both `l` and `l[0]` refer to the same underlying array, so their first
elements have the same address.
`l[0] = l` would be fine for me, indeed. Though I am not sure I understand
the suggested solution. Notice that the type of the slice is
`[]interface{}`. This...
ll := l[0].([]interface{})
println( == )
...would print `false`.
I think the main challenge is that l and ll, or l[0] for that
11 matches
Mail list logo
