A quick correction to my own comment:
On Sun, Oct 1, 2023 at 8:35 PM Patrick Smith wrote:
> The problem with your code is that "T comparable" guarantees that two
> values of type T can be compared,
>
... but then I remembered the comparison can still panic at runtime, as per
https://go.dev/doc/
On Sun, Oct 1, 2023 at 7:30 PM Jon Watte wrote:
> I want to implement a generic function to "remove nil values from a
> slice." This should be able to remove nil instances of error, for example.
> So, let's say I have:
>
> var arg = []error{nil, errors.New("oh noes"), nil}
>
> Unfortunately, this
> It seems to me `== nil` is a better way to spell that, than a function
call. And a generic function can always do `v == *new(T)` to check if a
value is the zero value.
Bringing this up because I found it from a thread on Google.
I want to implement a generic function to "remove nil values fr
Axel Wagner, you opinin is highly appriciated.
niedziela, 1 października 2023 o 15:00:35 UTC+2 Axel Wagner napisał(a):
> On Sun, Oct 1, 2023 at 2:37 PM Jerry Londergaard
> wrote:
>
>> I've been thinking about this point as well lately. I think I understand
>> (at least some of) the conditions
Weeell, I had unit tests running without hiccup on a wide range of
devices, and only a year later some of them started to fail with a
seemingly "leaked" (non-restored) namespace. The question here and the
suggested issue then introduced me to the "wedged" M0 thread. It works
until it doesn'
> In Go, so far changes were for the better and I'm glad to change my
learning if it benefits the mass of my fellow developers.
Maybe. Let's see how times handle it.
TD;DR;
I praise for changes but it is not easy.. I mean, look at our society (the
final reflection of us as an unique aggregated
On Sun, Oct 1, 2023 at 2:37 PM Jerry Londergaard
wrote:
> I've been thinking about this point as well lately. I think I understand
> (at least some of) the conditions under which
> you would call a panic(), but I still don't quite grok why it's better
> than returning an error if that error is pr
I've been thinking about this point as well lately. I think I understand
(at least some of) the conditions under which
you would call a panic(), but I still don't quite grok why it's better than
returning an error if that error is properly
handled. If I panic(), then no defer() statements will
Thanks Burak. I think that makes sense. You can perhaps still think of that
approach as defining the interface "where it's used", even if it's not quite
as close to where it's used as is technically possible. It still has its
caveats,
but it does seem better than defining it where it's implemented
actually, language changes happen all the time. In German, there is quite
some "misuse" esp. by journos that change or follow change in German, not
necessarily improving clearness. In Go, so far changes were for the better
and I'm glad to change my learning if it benefits the mass of my fellow
10 matches
Mail list logo
