On Wednesday, July 26, 2017 at 9:16:50 PM UTC+1, Ian Lance Taylor wrote: > > On Wed, Jul 26, 2017 at 1:07 PM, Florin Pățan <[email protected] > <javascript:>> 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 >
Thank you so much for the quick reply 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
