>
>
> If I know that a value exists, or am fine using the zero value (again,
> that's the majority of my personal use-cases for maps at least), having to
> use a statement just to discard the extra bool is annoying.
>
Right, so this brings me back to a nice solution to both our use cases,
which would be to initialize the map as either having a default or not
having a default. You don't have to check for failure, I don't have to
worry about forgetting to check for failure... right? :D
FWIW, using `map[K]bool` as a set is a great example for where this
> behavior is super convenient. Far more convenient than if you use
> `map[K]struct{}`, which has significant syntactical overhead.
>
Sure, that's a bad alternative. So again, back to my original theory,
seems like an overall better option to have `map[K]bool(false)` if you want
the default to be false vs `map[K]bool` if you don't. Or perhaps
`openMap[K]bool` if you want every key to return something vs
`closedMap[K]bool` if you don't.
> Well, an exception-based language of course is less hesitant to throw
> exceptions. But as a result, they often get ignored and cause crashes with
> useless stack traces (useless to the user, that is - the developer might
> find them more useful, but as a user, I want to know what I did wrong
> *without* having to look at source code).
>
Fair point :)
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...)
>>
>
> It's something you could do for your code base, for sure. But personally,
> I'd consider doing that bad style. Only check for membership, if membership
> is actually important.
>
Well I definitely agree there about the ideal state - I should only have to
check for membership when membership is important ideally. So wouldn't it
also be ideal to allow the developer to indicate when membership is
important vs when it's not upon initialization, so that the runtime can
panic when panic is appropriate, and just move along when "there's nothing
to see here" - all without requiring any convention or ongoing discernment
from maintainers of a code-base?
(And maybe not even panic, but just require checking for failure in one
case, but not in the other, so that mistakes can be caught at compile
time!) :D
--
*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/e2636a6e-8478-44eb-bc44-e0b0a8d3b5cbn%40googlegroups.com.
