On Saturday, June 13, 2020 at 1:09:16 PM UTC-4, Jan Mercl wrote:
>
> On Sat, Jun 13, 2020 at 5:37 PM Jake Montgomery <jake...@gmail.com 
> <javascript:>> wrote: 
>
> > You cant really write a short 'end()' function. You have to write an end 
> function for every type of slice. Or use reflection, which would make the 
> function slow, and not inlined. Generics anyone? 
>
> I haven't mentioned anything about the function being universal. IMO 
> in the majority of cases, it does not have to be. Why is such 
> limitation being inserted? 
>

Yes, it was an insertion on my part. My point was that you cant just write 
a [single] performant end() function, you have to write lots of them. 
However, it was based on the original problem stated. Here was my 
reasoning. There is already a really short and very fast way of accessing 
the end of a slice: s[len(s)-1]. The OP seemed to indicate that he wanted 
something that would be used universally, and reflexively, instead. 
Something that would be more clear, and less error prone. It seems like it 
would be a hard sell to convince coders to stop, check if the function 
already existed, then probably switch files, and write a new end() 
function, every time they want to access the last element of a new slice 
type, instead of just typing a few characters.

It takes probably less time to write the "specialized" end function 
> than we have already spent discussing it. And that's assuming it's a 
> good idea to do so in the first place, which I don't really accept. 
>

If I have to write a new one for every slice type, and then check or 
remember  if it exists every time I use it, then I would argue that it 
would add up to a great deal of time and cognitive energy over the life of 
a project. Certainly more than was spent, by me anyway, on this discussion. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/00c1e93e-bfbc-47b3-a95d-68db4cea0429o%40googlegroups.com.

Reply via email to