Regards,
Alberto
On Friday, December 6, 2013 10:44:32 PM UTC+1, Dave Cheney wrote:
Why not do this ? http://play.golang.org/p/BwYOhCQ4Fi
I
its
annoying
get me
rather than
at
dictionary
really
which
http://www.google.com/trends/explore#q=golang%20set%2C%20golang%20map%2C%20golang%20slice%2C%20golang%20channel&cmpt=q
to
values
wrong
confusing
or
--
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] <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.
--Why not do this ? http://play.golang.org/p/BwYOhCQ4Fi
On Sat, Dec 7, 2013 at 6:13 AM, Arne Hormann wrote:
Am Freitag, 6. Dezember 2013 18:54:54 UTC+1 schrieb Islan Dberry:
or a little nicer:
exists := struct{}{}
wrote:Am Freitag, 6. Dezember 2013 18:54:54 UTC+1 schrieb Islan Dberry:
You can eliminate some of those pesky {} by defining a type:
type setval struct{}
myset := make(map[whatever}setval)
myset[key] = setval{}
type setval struct{}
myset := make(map[whatever}setval)
myset[key] = setval{}
or a little nicer:
exists := struct{}{}
On Friday, December 6, 2013 9:46:11 AM UTC-8, Alberto García Hierro
Hi,
I've been using map[whatever]struct{} whenever I need a set. However,
I've been using map[whatever]struct{} whenever I need a set. However,
see a few downsides to this approach:
- It's ugly. mymap["foo"] = struct{}{} looks incredibly out of place,
since almost no other Go construct uses two consecutive {} (ofc,
map[string]interface{}, but that almost always includes some values in
- It's ugly. mymap["foo"] = struct{}{} looks incredibly out of place,
since almost no other Go construct uses two consecutive {} (ofc,
map[string]interface{}, but that almost always includes some values in
initialization, not creating a second {}).
- Requires a lot of typing, and so many { and } are incredibly
- Requires a lot of typing, and so many { and } are incredibly
on most non-US keyboards since we need to hold down AltGr (and don't
started on not releasing the AltGr fast enough and typing U+00A0
space!).
- It's not intuitive. Neither the Go spec nor the Go Tour mention sets
- It's not intuitive. Neither the Go spec nor the Go Tour mention sets
all. I mean, for most people is pretty obvious that you can use a
as a set, but most people expect a builtin set type or something
close, so they waste time looking for it.
- It's not really documented anywhere. I can't find any references to
struct{} having == and != defined nor struct{} taking 0 bytes.
- It's not obvious. Lots of people end up using map[whatever]bool,
- It's not really documented anywhere. I can't find any references to
struct{} having == and != defined nor struct{} taking 0 bytes.
- It's not obvious. Lots of people end up using map[whatever]bool,
wastes space.
Some interesting data from Google Trends:
Some interesting data from Google Trends:
People search for "golang set" 2/3 a much as "golang channel".
What I propose is a slight modification to the language, allowing maps
What I propose is a slight modification to the language, allowing maps
omit the value type, resulting in a set.
m := make(map[string])
This value-less map can use the same delete() function to remove
m := make(map[string])
This value-less map can use the same delete() function to remove
from it. However, when it comes to inserting values I see three
possibilities:
1 - m["key"] = nil
I don't like this one much, but is the approach which requires the
smaller number of changes to the language. Obviously, trying to assign
anything but nil to a value-less map should generate an error.
2 - set(m, "key")
This looks good and is intuitive, but requires adding a new keyword to
the language, potentially breaking existing codebases.
3 - append(m, "key")
This does not require any new keywords, but it might give users the
possibilities:
1 - m["key"] = nil
I don't like this one much, but is the approach which requires the
smaller number of changes to the language. Obviously, trying to assign
anything but nil to a value-less map should generate an error.
2 - set(m, "key")
This looks good and is intuitive, but requires adding a new keyword to
the language, potentially breaking existing codebases.
3 - append(m, "key")
This does not require any new keywords, but it might give users the
impression that the keys are ordered. Furthermore, it could be
since slices would require slice = append(slice...) while value-less
wouldn't need the assignment.
So, what are your thoughts? Do you think map[type]struct{} is enough
wouldn't need the assignment.
So, what are your thoughts? Do you think map[type]struct{} is enough
would you like some improvements in that area?
Regards,
Alberto
Regards,
Alberto
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] <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.
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/groups/opt_out.