Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

proposal: spec: user-defined map keys #283

Closed
gopherbot opened this issue Nov 20, 2009 · 9 comments
Closed

proposal: spec: user-defined map keys #283

gopherbot opened this issue Nov 20, 2009 · 9 comments
Labels
FrozenDueToAge LanguageChange v2 A language change or incompatible library change
Milestone
Unplanned

Comments

@gopherbot
Copy link

by jbamsterdam:

The valid types for map keys are limited. User-defined types that meet the 
appropriate criteria (e.g. having Hash and Equals functions) should be 
permitted.

Alternatively, consider a library package that exposes the internal map 
implementation in a general way.
@robpike
Copy link
Contributor

robpike commented Nov 20, 2009

Comment 1:

Status changed to LongTerm.

@rsc
Copy link
Contributor

rsc commented Dec 2, 2009

Comment 2:

Labels changed: added languagechange.

@rsc
Copy link
Contributor

rsc commented Dec 9, 2011

Comment 4:

Labels changed: added priority-later.

@rsc
Copy link
Contributor

rsc commented Jan 29, 2012

Comment 5:

You can use structs as map keys now.

Labels changed: added priority-someday, removed priority-later.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 6:

Labels changed: added repo-main.

@rsc
Copy link
Contributor

rsc commented Mar 3, 2014

Comment 7:

Adding Release=None to all Priority=Someday bugs.

Labels changed: added release-none.

@rsc
Copy link
Contributor

rsc commented Apr 10, 2015

Moving priority-someday to the Unplanned milestone.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015
Arista-Jenkins pushed a commit to aristanetworks/goarista that referenced this issue May 2, 2016
@tsuna
key: Make map[Key]interface{} always O(1) with some runtime hacks.
59d8141 
This is based on a POC from Frank Somers.
This is a workaround for golang/go#283.

Before:
BenchmarkBigMapWithCompositeKeys-8      2000   2863709 ns/op

After:
BenchmarkBigMapWithCompositeKeys-8  10000000       573 ns/op

Unsurprisingly, the O(N) implementation is super slow with a map size of
10000 entries, compared to the O(1) implementation.

Change-Id: Ia9ed056218c59e77b64aceb59e23b95d37760e85
@tv42
Copy link

tv42 commented Jul 28, 2016 •
edited

You could maybe use https://tip.golang.org/pkg/reflect/#StructOf instead of a map, to make compound keys with arbitrary components.

@rsc rsc changed the title ponies: user-defined map keys proposal: spec: user-defined map keys Jun 20, 2017
@rsc rsc added the v2 A language change or incompatible library change label Jun 20, 2017
@ianlancetaylor
Copy link
Contributor

I'm going to close this. If we had generics (#15292) that would be a better approach to this. Or, write your own wrapper functions that use a map[uint64][]T and write a hash function from T to uint64 and code that uses your equals function on each element in the slice. Or something like that. Anyhow, we aren't going to add this particular case to the language itself, except via generics.

@dsnet dsnet mentioned this issue Mar 1, 2018
Open
@golang golang locked and limited conversation to collaborators Nov 29, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge LanguageChange v2 A language change or incompatible library change
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
5 participants
@rsc @tv42 @ianlancetaylor @robpike @gopherbot