On Wed, Jul 26, 2017 at 1:07 PM, Florin Pățan <florinpa...@gmail.com> wrote: > > I would like to understand a bit better one particular implementation > decision regarding the new sync.Map feature. > > Besides having to introduce a new keyword to the language and some compiler > work, what were the other issues that pushed the implementation as part of > the standard library instead of the language itself? > > And, obviously, since everyone is talking these days about Go 2, would > having a newer version of the language at some point in the future, maybe Go > 1.14, help in moving this from the standard library to the language? > > The reason I ask is because the Go compiler / runtime already have a form to > express maps and ensure that, once a map is declared, the keys and values > will always be of the same type. The current sync.Map implementation however > allows for everything to be set as keys and values which means a lot of type > safety checks in the compiler are lost to the runtime. > > If this was already discussed, can you please link to that discussion as > I've not managed to find it myself.
Adding a new complex feature to the language is a high bar. sync.Map is a somewhat special purpose data structure. We don't want to add all potentially useful data structures to the language. Especially not if they can be implemented entirely as a library, even if the resulting library does lose some compile-time type safety. Ian -- 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. For more options, visit https://groups.google.com/d/optout.
