Thanks for the insights!
Yeah, I can see how the convention of "always testing for failure" is
better than a panic, in that it requires you to handle the possibility of a
failure for things that may commonly fail. In that respect though, I don't
understand why the "comma OK" is optional. Elm, for instance, handles
things similarly, and has no panics or errors at all as a result because it
enforces handling of every possible outcome. But in Go, it seems like...
in places where it's not easy to use "comma OK" (maybe in the middle of a
larger expression), or if I forget, I could easily confuse the default
result from a boolean map (false) with an actual false value! In Python or
Elm, or Ruby, there would be a clear distinction and/or a panic.
I agree that it's not a common case that you might want a panic - in fact I
*never* want a panic, haha! I suppose it's more of a question of language
convention vs. language enforcement. Because I'm human, and rarely write
perfect code, I would prefer for the compiler (or the runtime environment)
to have an error if I make a mistake like that. And even if in 90% of
cases, it's not a mistake and can be resolved by using a sensible default
value, if in 10% of cases it IS a mistake, I feel like it makes more sense
that the language should enforce handling it, while making it easy to
specify a default for the 90% of cases where one is actually appropriate.
In the current situation, there's no way for me to guard against mistakes
in code maintenance. I can intentionally panic in a particular instance,
but if I'm maintaining the code a year later, and make a mistaken
assumption about the existence of a key, intentionally checking and
panicking in that case isn't really an option/solution since the definition
of the context is that it's unintentional :D
I suppose maybe there's a way to setup a style linter to enforce a failure
check for every map access? (But that's a lot more tedious than just
enabling a default where appropriate, or disabling it where it's not...)
On Thursday, August 13, 2020 at 2:11:47 PM UTC-5 Michael Jones wrote:
> Joe, your question is perfectly answered by Axel.
>
> I'll just share a few (personal) Go "style" comments:
>
> Go likes you to test explicitly for failure where that is possible: did
> the open fail, did the pipe break, etc.Multiple return values make this
> clear by avoiding the need for a "reserved" error value of the normal-case
> return.
>
> Go likes untested actions to work. In your case adding an existing key to
> a map replaces the old entry, accessing a missing entry returns the default
> value. ["no surprises"]
>
> Go likes you to combine these approaches to make your own more elaborate
> behaviors using the "comma OK" approach that Axel shared. In your case,
> adding, and deleting could complain if there is already a matching entry,
> or not a matching entry, or -- and this is the real reason -- by looking at
> the payload of a new or matching entry to use application logic to decide
> if that's ok or not. Only you can know so Go won't second guess you, and
> the test-rather-than-panic style is because testing right there is deemed
> the right way.
>
>
> On Thu, Aug 13, 2020 at 11:42 AM 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> No, there isn't, but you can check if the value exists:
>>
>> x, ok := m[k]
>> if !ok {
>> panic("does not exist")
>> }
>>
>> You can also wrap that with methods, if you want to avoid the extra check.
>>
>> I disagree with you that panicking on a non-existent key is better -
>> either in general, or in the majority of cases. Personally, I don't think I
>> encountered many use-cases where the zero-value wasn't the perfect thing to
>> use. I'm not saying your use-case doesn't exist or even that it's rare,
>> just that I don't think you can generalize from your experience here.
>>
>> On Thu, Aug 13, 2020 at 8:36 PM Joe Marty <joe....@smartersorting.com>
>> wrote:
>>
>>> I'm very new to Go - apologies in advance if I'm missing something:
>>>
>>> I find it frustrating that there's no way to create a map that does
>>> *not* automatically return a zero value for undefined key access by default.
>>>
>>> I love the fact that Go doesn't return "nil" for this use case (I love
>>> Ruby, but I don't think they got that quite right), but returning a default
>>> value is worse! It would make so much more sense if it would just panic
>>> when accessing an undefined key. I'm not a Python guy, but I think this is
>>> something Python got right.
>>>
>>> Creating a map that returns some default value when you access an
>>> undefined key should be a special kind of map, or a special argument to
>>> initializing the map (which Ruby does allow). In Go, is there even any way
>>> to create a map that panics when you access an undefined key?
>>>
>>> -Joe
>>>
>>> --
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/f53377a0-ddc1-4842-ac7a-a796d85b7077n%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/golang-nuts/f53377a0-ddc1-4842-ac7a-a796d85b7077n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
>> 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...@googlegroups.com.
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEc5MO-FS1esLDJGoKRUq0tneJ5v6GR5T8JQMDFgjx9pQ%40mail.gmail.com
>>
>> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEc5MO-FS1esLDJGoKRUq0tneJ5v6GR5T8JQMDFgjx9pQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>
>
> --
>
> *Michael T. jonesmichae...@gmail.com*
>
--
*Connect with us here:* LinkedIn
<https://www.linkedin.com/company/smarter-sorting/>, Facebook
<https://www.facebook.com/smartersorting>, Instagram
<https://www.instagram.com/smartersorting/>, Twitter
<https://twitter.com/SmarterSorting>, BuiltInAustin
<https://www.builtinaustin.com/company/smarter-sorting>
<https://www.smartersorting.com/>
<https://www.builtinaustin.com/2019/02/05/50-austin-startups-watch-2019?utm_source=PE&utm_medium=organic_social&utm_campaign=50_STW_PE&utm_term=article&utm_content=austin>
--
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/3be33769-aa34-491d-af25-dbfe362807c5n%40googlegroups.com.
