Thanks Jake.
The logic about the slice being reused across iterations makes sense.
I will run these tests on my machine.
On Monday, 17 February 2020 08:48:12 UTC+11, Jake Montgomery wrote:
>
> Without speaking to the correctness of your algorithm, I can tell you why
> your results are not as you
Thanks Jake. That makes sense.
Because the slice was being reused as-is for each iteration, the QuickFind
was finishing much faster than the QuickUnion. That is because the find
part in the QuickFind function returned immediately as all pairs got
connected in a previous iteration.
I am
Maybe an eye opener, but why is everyone obsessed with the try..catch.. Or
try..catch..else error handling? Are we trying to copy idioms from another
language?
The try..catch..finally in java has always played part in newbie bugs. They
tend to skip the error instead of dealing with it.
I prefer
Right? I’m with you here. So thankful with the custodians that prefer cleaner
syntax over complex and shorter ones.
On Feb 16, 2020, 15:39 -0400, Kevin Chadwick , wrote:
> I prefer the clarity of the current syntax. What is the obsession with LOC.
>
> > I would further suggest f ?=
Hi,
My present from golang.org/x/tools is too old to be functioning properly:
$ present
2020/02/16 18:13:07 Failed to parse templates: template: slides.tmpl:65:
function "pagenum" not defined
So I did `go get -v -u golang.org/x/tools`. However, my present is not
updated and still giving me
Without speaking to the correctness of your algorithm, I can tell you why
your results are not as you expect. It is a classic benchmark mistake. You
are creating your slice, filled with ordered integers, then running your
code on the same slice again and again. So after the first iteration the
> One reason for not implementing it in the standard library is that there
> are many possible implementations. Do you want to reverse combining
> character sequences for example? Unicode is a complex beast and I suspect
> that reversing a string rune-by-rune may easily break important
>
I prefer the clarity of the current syntax. What is the obsession with LOC.
>I would further suggest f ?= os.os.Open("filename.ext") :
>log.fatal("Cant
>open filename.ext")
>But the GO 'custodians' get apoplexy whenever they see any syntax that
>resembles the C ternary operator.
>Chill-out
Great suggestion
f := os.Open("filename.ext")
else err != nil {
log.Fatal(err)
}
is much needed syntax improvement vs the current syntax.
I would further suggest f ?= os.os.Open("filename.ext") : log.fatal("Cant
open filename.ext")
But the GO 'custodians' get apoplexy whenever they see
On Sun, Feb 16, 2020 at 12:11 AM Andreas Otto wrote:
>
> Ok, but that has massive consequences:
>
> 1. in order to bridge this, the code has to be changed to "cast" -> so the
> type safety is lost
> 2. or the NULL pointer test is drawn at the top, in the "caller" -> but this
> is a MASSIVE
One other thing: unless you change the entire syntax of the go language,
your proposed "else" modifier needs to go on the same line as the statement
it relates to.
For the reason see: https://golang.org/doc/faq#semicolons
--
You received this message because you are subscribed to the Google
Code like this:
f, err := os.Open("filename.ext")
if err != nil{
log.Fatal(err)
}
would become:
f := os.Open("filename.ext")
else err != nil {
log.Fatal(err)
}
The `err` variable in the example above is automatically initialized to the last
return value of the function call
Anybody? My question was not meant to criticize vim-go or gopls, if they
can't (yet) do what I want those tools to support me, but a honest
questions if I do not know how to use the tools.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
Ok, but that has massive consequences:
1. in order to bridge this, the code has to be changed to "*cast*" -> so
the type safety is lost
2. or the *NULL* pointer test is drawn at the top, in the "caller" -> but
this is a MASSIVE change to the existing CODE basis.
3. In "*C*" the call of a method
14 matches
Mail list logo
