Re: [go-nuts] "find" for Slices like "append"

Sort.Search is nice, but then the list has to be sorted. Wasnt there a lenghty discussion on how awkward sorting is compared to other languages, and then in 1.8. finally someone implemented func Slice(slice interface{}, less func(i, j int ) bool

Re: [go-nuts] "find" for Slices like "append"

> > > The Go philosophy is explicitly *not* to give you everything you want. > It *is* to give you everything you need to build everything you want, > like Lego. > Yeah right, when men still where real men and programmed their own device drivers... Or take a car, give me parts & tools and I

Re: [go-nuts] "find" for Slices like "append"

Volker thanks for the reply. Coming from Python I can do a simple test like if item in my_array: # do something else: # do something else I can understand that it cannot be that easy in Go (and then, why not, "equals" is already defined), but image you have to use a for-loop every time or

[go-nuts] "find" for Slices like "append"

Being fairly new to Go, I am trying to evaluate if it s possible and worth to move our huge C++ codebase over to Go. 1) append(sliceA, my_new_item) sliceA Why can I not append something to a Slice in place, why does it have to return a new Slice? 2) find(sliceB, item_i_look_for) int, -1 for

Re: [go-nuts] "find" for Slices like "append"

> > > > Why can I not append something to a Slice in place, why does it have to > > return a new Slice? > > https://blog.golang.org/slices > > Ok, I will check that, thx. > > > 2) find(sliceB, item_i_look_for) int, -1 for not found > > > > Why can I not find easily search for an item

Re: [go-nuts] "find" for Slices like "append"

> > > Because it's easy to write a short correct find loop for the type you > are using, but a good implementation of append is a much larger > function. See also http://www.airs.com/blog/archives/559 . > So "append" is already done. May I propose to implement a generic "find" function?

Re: [go-nuts] Re: error handling needs syntactical sugar

On Tuesday, September 5, 2017 at 10:39:05 AM UTC+2, Rob 'Commander' Pike wrote: > > If you find that lines like if err != nil are a significant fraction > of non-test code, your code probably needs a better error handling > strategy, not a language change. I have done measurements in the past

[go-nuts] Re: error handling needs syntactical sugar

On Monday, September 4, 2017 at 10:48:06 PM UTC+2, Tamás Gulácsi wrote: > > Why do you Prepare a statement if you don't reuse it? Just use a db.Exec. Just wanted to show a pattern which I see very often in Go code. Its not a working example, and I am not asking for improvements in that code.

[go-nuts] Re: error handling needs syntactical sugar

Hi Dorival, thanks for supporting me with my idea. And yes, after writing my post yesterday I was thinking, "watchif" or even simply "watch". And yes, today I am more in favor of simply *"watch"*. And yes, we can constrain this to the context of one function (like defer), I am ok with that.

Re: [go-nuts] error handling needs syntactical sugar

> > > You don't. But it's a bad idea. And "I want to make writing bad code > easier" isn't a very convincing argument for a language-change. > Ok, than I want to - Make it easier to read and follow - Make it possible to handle errors in one place instead of 10 I see you point, and yes,

Re: [go-nuts] error handling needs syntactical sugar

Dorival, thanks for counting your error calls, but without any other number showing the size of your project they cannot really put in perspective ;-) And I think *watch* should not only be function bound, but bound to the current scope, same as *var*. Martin On Tuesday, September 5, 2017

[go-nuts] Re: error handling needs syntactical sugar

Dorival, I think we can celebrate already if we achieve anything with this discussion. Let's not ask for too much, plus let's not make it too complicated. I think your proposed "watch err", hides too much and does too little. You can simply write (the inline code editor is broken, BTW) func

Re: [go-nuts] error handling needs syntactical sugar

Axel, thanks for the reply. As I already replied to Tomas, I am not looking for improvements in this particular case where I need to call an SQL database. An no, I dont want to wrap all function I use into something which collects the errors for me. Let's say you want to log & panic & exit

[go-nuts] error handling needs syntactical sugar

Hi guys, at first I though I really like the idea of how Go deals with error management and handling, but the more Go code I look at or try to program, the more I get scared about checking errors every second line in every given block of code. Take a look at this example here from "Build Web