On 6 February 2018 at 21:25, wrote:
> What do you mean by a "slice pointer key" ?
>
>
> map[*[]Something]string
>
> Then map consumers can do key comparisons. I originally used this for an
> unordered set type.
>
I'm sure you are aware of the distinction but it might not be clear for
others rea
I went ahead and opened a Go 2
proposal: https://github.com/golang/go/issues/23725
Thanks,
Matt
On Tuesday, February 6, 2018 at 3:26:15 PM UTC-6, matthe...@gmail.com wrote:
>
> What do you mean by a "slice pointer key" ?
>
>
> map[*[]Something]string
>
> Then map consumers can do key comparison
>
> What do you mean by a "slice pointer key" ?
map[*[]Something]string
Then map consumers can do key comparisons. I originally used this for an
unordered set type.
Matt
On Tuesday, February 6, 2018 at 11:12:06 AM UTC-6, rog wrote:
>
> On 6 February 2018 at 14:55, > wrote:
> > Slice point
On 6 February 2018 at 14:55, wrote:
> Slice pointer keys are another option but that concept is tricky too.
What do you mean by a "slice pointer key" ?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop rec
Slice pointer keys are another option but that concept is tricky too.
Matt
On Tuesday, February 6, 2018 at 3:34:54 AM UTC-6, rog wrote:
>
> ... tick, tick, tick, tick... dide-dudi-diddlidedum...di!
>
> func comparable(xs []int) interface{} {
> type elem struct {
> first
On Tue, Feb 6, 2018 at 1:34 AM, roger peppe wrote:
> ... tick, tick, tick, tick... dide-dudi-diddlidedum...di!
>
> func comparable(xs []int) interface{} {
> type elem struct {
> first int
> rest interface{}
> }
> var r interface{}
> for
On 6 February 2018 at 09:34, roger peppe wrote:
> ... tick, tick, tick, tick... dide-dudi-diddlidedum...di
>
http://www.reactiongifs.com/wp-content/uploads/2011/09/mind_blown.gif
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe f
... tick, tick, tick, tick... dide-dudi-diddlidedum...di!
func comparable(xs []int) interface{} {
type elem struct {
first int
rest interface{}
}
var r interface{}
for _, x := range xs {
r = elem{x, r}
}
retur
On 5 February 2018 at 11:38, Peter Waller wrote:
> On 5 February 2018 at 11:04, roger peppe wrote:
>>
>> > I'll bite, does it involve struct { len int; content [maxCount]int }, or
>> > did
>> > you have something else in mind?
>>
>> Something else. No size limit. Not what one might call efficient
On 5 February 2018 at 11:04, roger peppe wrote:
> > I'll bite, does it involve struct { len int; content [maxCount]int }, or
> did
> > you have something else in mind?
>
> Something else. No size limit. Not what one might call efficient though. :)
>
[low growling]
(ok, so I've been watching Str
On 5 February 2018 at 08:36, Peter Waller wrote:
> On 31 January 2018 at 16:23, roger peppe wrote:
>>
>> BTW you can already do something like this:
>> https://play.golang.org/p/q4bz8-AckN3
>
>
> Neat trick!
>
>>
>> You can even do it without reflect, which I'll leave as an exercise for
>> the re
On 31 January 2018 at 16:23, roger peppe wrote:
> BTW you can already do something like this:
> https://play.golang.org/p/q4bz8-AckN3
Neat trick!
> You can even do it without reflect, which I'll leave as an exercise for
> the reader :)
I'll bite, does it involve struct { len int; content [m
On Fri, Feb 2, 2018 at 9:59 PM, wrote:
>
> Each path represented as a slice of coordinates could be easily encoded to
> a string and compared that way.
>
Ah, I misunderstood "path".
>
> As far as resource expenses go, we'd need benchmarks to say much. I
> understand looking at expensive cases t
>
> Are you sure that's the only edge-case? Because this thread is kinda long
> and there might even be things we are not thinking about.
In the original discussion above I see one opinion toward comparing headers
and four toward by element values (like strings). I didn't see any
additional
On 30 January 2018 at 23:19, wrote:
>> - When slices can be compared, they can be used as map keys. What happens
>> if the contents of a slice are changed after it has been added to a map?
>
>
> I’m not too familiar with Go map internals, but my thought is the key hash
> would depend on the backi
> What about a proposal addition of “types with self-references in slices
cannot be compared”?
Are you sure that's the only edge-case? Because this thread is kinda long
and there might even be things we are not thinking about.
> I’m curious about examples where people wanted one or the other. I o
I agree with you Axel. One point is that allowing struct comparison but not
slice comparison was counterintuitive to me at first.
What about a proposal addition of “types with self-references in slices
cannot be compared”?
While comparison by header versus comparison by value may not be an obvi
On Wed, Jan 31, 2018 at 12:19 AM, wrote:
> - When slices can be compared, they can be used as map keys. What happens
>> if the contents of a slice are changed after it has been added to a map?
>
>
> I’m not too familiar with Go map internals, but my thought is the key hash
> would depend on the b
Correction on the self-reference example:
a0 := A{}
// equal
a1 := A{a0, A{}}
a1[0] = a1
a2 := A{a1, a1[1]}
// not equal
a3 := A{A{a1, a1[1]}, a1[1]}
Thanks,
Matt
On Tuesday, January 30, 2018 at 5:19:44 PM UTC-6, matthe...@gmail.com wrote:
>
> - When slices can be compared, they can be used as m
>
> - When slices can be compared, they can be used as map keys. What happens
> if the contents of a slice are changed after it has been added to a map?
I’m not too familiar with Go map internals, but my thought is the key hash
would depend on the backing array values. Go maps also allow read
Two significant issues that need to be thought about:
- When slices can be compared, they can be used as map keys. What happens
if the contents of a slice are changed after it has been added to a map?
- It is possible to have self-referential slices [1]. How would comparison
work in such a case?
Here’s a draft for a Go 2 proposal that I’d like to add to the issue
tracker since there’s no discussion there about this:
Slices should have equality defined.
https://golang.org/doc/faq#map_keys
Map lookup requires an equality operator, which slices do not implement.
> They don't implement eq
I realize that the issue might be about changing/ adding a builtin:
- either add a builtin deep value Comparison function (via reflection)
- or add a snapshot type refinement which triggers the allocation of an
immutable copy of a reference type
(and we would recover the behaviour of
Actually that's my mistake. It is spec'ed but not in the bullet points.
https://golang.org/ref/spec#Comparison_operators
Still, I find this hairy.
On Monday, July 4, 2016 at 12:52:11 AM UTC+2, Chad wrote:
>
> To illustrate.
> I think that an issue should be raised.
>
> https://play.golang.org/p/e
To illustrate.
I think that an issue should be raised.
https://play.golang.org/p/eiwG-4vsnJ
--
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+unsubsc
On Monday, July 4, 2016 at 12:09:57 AM UTC+2, as@gmail.com wrote:
>
> I wish I could be pointed to such discussion.
>>
>
> It was briefly discussed in *The Go Programming Language *book by Donovan
> & Kernighan (p 132)
>
> *:*
>
>> An analogous “shallow” equality test for slices could be use
>
> I wish I could be pointed to such discussion.
>
It was briefly discussed in *The Go Programming Language *book by Donovan &
Kernighan (p 132)
*:*
> An analogous “shallow” equality test for slices could be useful, and it
> would solve the problem with maps, but the inconsistent treatment o
I wish I could be pointed to such discussion.
> The language authors omitted this functionality for a reason. One of the
> reasons is that arrays and slices are similar, and changing their
> comparison semantics seemed confusing.
>
https://blog.golang.org/slices specifically mentions that arra
I was being facetious. You have the right to opine, but elevating opinions
to that of proofs doesn't give the discussion any utility. I think you
should consider the underlying assumptions in some of your points:
1. A slice is a descriptor of an aggregate
2. A struct can resemble a descriptor o
Pardon?
On Sunday, July 3, 2016 at 8:13:30 PM UTC+2, as@gmail.com wrote:
>
> Hardcoded proofs should be assigned well-named identifiers. If you ever
> have to alter them, you don't want to be rummaging around your lemmas and
> corollaries.
>
> On Sunday, July 3, 2016 at 5:32:26 AM UTC-7, Cha
Hardcoded proofs should be assigned well-named identifiers. If you ever
have to alter them, you don't want to be rummaging around your lemmas and
corollaries.
On Sunday, July 3, 2016 at 5:32:26 AM UTC-7, Chad wrote:
>
> Ok. That "haha" was merely to show that no animosity was borne. And also
>
Ok. That "haha" was merely to show that no animosity was borne. And also
because you didn't really answer the question as I asked (by quoting the
spec) which I found funny.
Alas, I guess we couldn't see eye to eye.
But chill a little bit. I have given all the hardcoded proofs and people
have j
I'm sorry but your attitude is counterproductive to the discussion.
"haha" what? I told you I see your point, I think I know the specs very
well, thank you for the link.
However, you seem incapable of accepting, despite an number of others
saying the contrary, despite, given a reasonable example
Ok, Let me help you out haha :)
Here is the definition of a slice. It is not a container.
https://golang.org/ref/spec#Slice_types
I am not inventing things.
I know what people on this thread said, but that's their misconception.
On Sunday, July 3, 2016 at 1:40:46 PM UTC+2, Florin Pățan wrote:
>
As you pointed out, Printf() should follow the ref spec but that doesn't
happen because some humans don't perceive this accuracy as necessary or
maybe because the way to resonate about slices / arrays is as containers
for the actual values.
Thus we have Printf working as it does (and %p will ind
In fact, that is somewhat my fault.
I should ask:
What is a slice?
What is an array?
Spoiler: a slice is a reference type in its "wikipedia-ish" definition
(auto-dereferencing) which is the reason you observe such a result in the
playground.
On Sunday, July 3, 2016 at 1:12:17 PM UTC+2, Chad w
No. You should not get it from here. You should get the answer from the
spec. Let alone the fact that the implementation should ideally follow the
spec and not the reverse.
On Sunday, July 3, 2016 at 1:03:44 PM UTC+2, Florin Pățan wrote:
>
> If I look at what %v means, print out the values of va
If I look at what %v means, print out the values of various types in Go,
according to https://golang.org/pkg/fmt/ then I believe that this holds the
answer: https://play.golang.org/p/GiLckoBDxa
On Sunday, July 3, 2016 at 11:33:01 AM UTC+1, Chad wrote:
>
> Not for comparison.
>
> I am just asking
Not for comparison.
I am just asking what is the value of a slice and what is the value of an
array.
Remember that there is no slice comparison that has been spec'ed so far.
On Sunday, July 3, 2016 at 12:24:05 PM UTC+2, Florin Pățan wrote:
>
> For []T the value of a slice for the purpose of com
For []T the value of a slice for the purpose of comparison would be each
individual value compared against each-other (ofc maybe comparing the
length first as an optimization).
Same goes for an array.
And again, you are missing the whole point. Both me and you are wrong in
each-others points of
What's the value of a slice?
What's the value of an array?
On Sunday, July 3, 2016 at 12:05:38 PM UTC+2, Florin Pățan wrote:
>
> If the type is *[]T then comparing memory addresses make sense to see if
> both terms point to the same memory address.
> If the type is []T then comparing memory addr
If the type is *[]T then comparing memory addresses make sense to see if
both terms point to the same memory address.
If the type is []T then comparing memory addresses doesn't make sense as
I'd expect to compare values.
Finally, if the type is []*T then I'd still expect to compare values (even
Which is why it should be formalized.
Where is the inconsistency between slices and arrays?
Why do people even think that a slice need to behave like an array wrt
equality, were it introduced?
A slice is not an array!
On Sunday, July 3, 2016 at 11:36:44 AM UTC+2, as@gmail.com wrote:
>
>
Relaxing unformalized behavior makes little sense to me. Explaining why
equality is inconsistent between slices and arrays is not something I want
to do either.
On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote:
>
> Rob and Robert actually wrote that this area of the spec needs more work.
Oh, maybe you mistook reference type for the notion of reference.
On Sunday, July 3, 2016 at 9:49:34 AM UTC+2, Martin Geisler wrote:
>
> Hi Chad,
>
> On Sat, Jul 2, 2016 at 10:43 AM, Chad >
> wrote:
> >
> > On Saturday, July 2, 2016 at 10:23:04 AM UTC+2, Martin Geisler wrote:
> >>
> >> On Fr
Rob and Robert actually wrote that this area of the spec needs more work...
Otherwise, the behaviour of maps, slices and funcs cannot be fully
explained.
On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as@gmail.com wrote:
>
> Go does not have reference types. As far as I know, the word was
> pu
Hi Chad,
On Sat, Jul 2, 2016 at 10:43 AM, Chad wrote:
>
> On Saturday, July 2, 2016 at 10:23:04 AM UTC+2, Martin Geisler wrote:
>>
>> On Fri, Jul 1, 2016 at 4:01 PM, Chad wrote:
>>>
>>> On Friday, July 1, 2016 at 3:44:10 PM UTC+2, Martin Geisler wrote:
I keep seeing references (hah!) to thi
Go does not have reference types. As far as I know, the word was purposefully
removed from the spec to remove the ambiguity surrounding the word.
https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA
--
You received this message because you are subscribed to the Google Groups
"golan
You can do that, but for correctness, I am arguing that it's not what you
should expect for slices by default.
On Sunday, July 3, 2016 at 3:37:15 AM UTC+2, Florin Pățan wrote:
>
> I would also expect to compare values not memory locations, generally
> that's what I'm interested in comparing.
>
>
I would also expect to compare values not memory locations, generally that's
what I'm interested in comparing.
I never had the need to compare equality for memory locations of anything in Go
(especially not for slices / maps oe their elements).
--
You received this message because you are subs
On Saturday, July 2, 2016 at 6:19:56 AM UTC+2, Matt Harden wrote:
>
> Conceptually, the value of a string is the sequence of bytes it contains,
> just like an array of bytes. It doesn't matter that the implementation of
> strings looks more like a slice internally. On the other hand the value o
On Saturday, July 2, 2016 at 10:23:04 AM UTC+2, Martin Geisler wrote:
>
> On Fri, Jul 1, 2016 at 4:01 PM, Chad >
> wrote:
> >
> >
> > On Friday, July 1, 2016 at 3:44:10 PM UTC+2, Martin Geisler wrote:
> >>
> >> On Fri, Jul 1, 2016 at 12:52 PM, Chad wrote:
> >> > However, that it's a valid
On Sat, Jul 2, 2016 at 6:19 AM, Matt Harden wrote:
> Conceptually, the value of a string is the sequence of bytes it contains,
> just like an array of bytes. It doesn't matter that the implementation of
> strings looks more like a slice internally. On the other hand the value of a
> slice is a ref
On Fri, Jul 1, 2016 at 4:01 PM, Chad wrote:
>
>
> On Friday, July 1, 2016 at 3:44:10 PM UTC+2, Martin Geisler wrote:
>>
>> On Fri, Jul 1, 2016 at 12:52 PM, Chad wrote:
>> > However, that it's a valid point you raise (re strings)
>> > But that's exactly the reason for which, someone would probably
Conceptually, the value of a string is the sequence of bytes it contains,
just like an array of bytes. It doesn't matter that the implementation of
strings looks more like a slice internally. On the other hand the value of
a slice is a reference to (part of) an underlying array, together with a
len
On Friday, July 1, 2016 at 4:01:54 PM UTC+2, Chad wrote:
>
>
>
> On Friday, July 1, 2016 at 3:44:10 PM UTC+2, Martin Geisler wrote:
>>
>> On Fri, Jul 1, 2016 at 12:52 PM, Chad wrote:
>> > However, that it's a valid point you raise (re strings)
>> > But that's exactly the reason for which, some
On Friday, July 1, 2016 at 3:44:10 PM UTC+2, Martin Geisler wrote:
>
> On Fri, Jul 1, 2016 at 12:52 PM, Chad >
> wrote:
> > However, that it's a valid point you raise (re strings)
> > But that's exactly the reason for which, someone would probably ask
> whether
> > a string is a reference ty
Yes. You're absolutely right.That's due to the current implementation of
strings.
Maybe they should be implemented as a struct with an unexported array of
byte
That would just work.
Having the string kind with the same structure as a slice is the problem
here. strings should probably be pure v
On Fri, Jul 1, 2016 at 12:52 PM, Chad wrote:
> However, that it's a valid point you raise (re strings)
> But that's exactly the reason for which, someone would probably ask whether
> a string is a reference type or a value type.
>
> This could probably made clearer in the documentation.
I keep se
On Fri, Jul 1, 2016 at 12:48 PM, Chad wrote:
> On Friday, July 1, 2016 at 12:11:43 PM UTC+2, Martin Geisler wrote:
>>
>> On Fri, Jul 1, 2016 at 3:15 AM, Chad wrote:
>> > No, it's actually fine. You are comparing values.
>> >
>> > A slice being a struct under the hood, for slices you would compare
However, that it's a valid point you raise (re strings)
But that's exactly the reason for which, someone would probably ask whether
a string is a reference type or a value type.
This could probably made clearer in the documentation.
On Friday, July 1, 2016 at 12:48:28 PM UTC+2, Chad wrote:
>
> O
On Friday, July 1, 2016 at 12:11:43 PM UTC+2, Martin Geisler wrote:
>
> On Fri, Jul 1, 2016 at 3:15 AM, Chad >
> wrote:
> > No, it's actually fine. You are comparing values.
> >
> > A slice being a struct under the hood, for slices you would compare the
> > structs (slice headers)
>
> Yes, wh
On Fri, Jul 1, 2016 at 3:15 AM, Chad wrote:
> No, it's actually fine. You are comparing values.
>
> A slice being a struct under the hood, for slices you would compare the
> structs (slice headers)
Yes, when you remember that a slice is a just a small struct with a
pointer and some bookkeeping in
On Thu, 2016-06-30 at 19:10 -0700, Chad wrote:
> I have explained why it was not sufficient upstream.
> I don't expect people to create two version of their types, one being
> for mere inclusion into maps.
>
Not really; you've said it's not necessary and you've pointed to
map[interface{}]interface
>
> You don't have to, you can use a pointer indirection instead.
>
>
I have explained why it was not sufficient upstream.
I don't expect people to create two version of their types, one being for
mere inclusion into maps.
--
You received this message because you are subscribed to the Google
On Thu, 2016-06-30 at 18:48 -0700, Chad wrote:
> Again, if you really understand the datastructure and what it
> represents, the behaviour is really not surprising. There is no value
> "abstraction".
CS and software engineering is abstractions all the way down.
>
> And currently, a comparison pan
Again, if you really understand the datastructure and what it represents,
the behaviour is really not surprising. There is no value "abstraction".
And currently, a comparison panics. Any interface comparison may panic if
the underlying type is a slice. I don't see a good reason for that.
That's
On Thu, 2016-06-30 at 18:15 -0700, Chad wrote:
> No, it's actually fine. You are comparing values.
The issue is that, yes while everything is a value, the value
abstraction is tenuous in this context. The result of this tenuous
abstraction is that there would be surprising behaviours (already
outl
No, it's actually fine. You are comparing values.
A slice being a struct under the hood, for slices you would compare the
structs (slice headers)
For an interface, you compare two pointers (in the current implementation)
etc.
"==" is just value comparison everywhere.
Everything is a value.
This position precludes the following use of the equality operator for
scalar values:
a := 1
b := 1
a == b would be false under the approach below since a and b are not the
same set of bits.
I think most people would find this a little surprising.
On Thu, 2016-06-30 at 09:24 -0700, Chad wrote:
I'd rather people were given a correct simple explanation rather than
foregoing any explanation because it may appear complex at first sight.
Especially since it alters how maps can be used, later on. (the hashing
algorithm relies on comparability).
On Thursday, June 30, 2016 at 10:32:58 PM UTC
2016-06-30 22:23 GMT+02:00 Chad :
>> Your proposition merely moves the semantical constraint to another
>> place: as Ian pointed out, if we define equality for slices to be
>> something resembling pointer equality suddenly []byte{1, 2} is not equal
>> to []byte{1, 2}.
>
>
> They are not since creat
> Your proposition merely moves the semantical constraint to another
> place: as Ian pointed out, if we define equality for slices to be
> something resembling pointer equality suddenly []byte{1, 2} is not equal
> to []byte{1, 2}.
>
They are not since creating a slice allocate a different un
On Thu, 30 Jun 2016 11:57:38 -0700 (PDT)
Chad wrote:
> In fact I'd rather deal with the general issue by relaxing some
> rules, if it's something that is deemed worthy of being dealt with.
I think this part of the discussion can be safely closed: since no one
is able to specify the semantics for
In fact I'd rather deal with the general issue by relaxing some rules, if
it's something that is deemed worthy of being dealt with.
Basically if you have a map[interface{}]interface{} because you have a
mixed bag of value that you fill at runtime, you cannot actually use any
type you want as th
On Thu, 30 Jun 2016 09:55:30 -0700 (PDT)
Chad wrote:
> I understand the worry but the more I think about it, the less I
> think it would end up being a real issue.
>
> Taking the example of maps... two different maps that have not the
> same location in memory are never equal, especially since m
I understand the worry but the more I think about it, the less I think it
would end up being a real issue.
Taking the example of maps... two different maps that have not the same
location in memory are never equal, especially since modifying one does not
modify the other. It's easily explained.
On Thu, Jun 30, 2016 at 9:24 AM, Chad wrote:
> It's a view in another array.
> Why should they be equal? Unless the second slice is constructed by
> subslicing the other as such `[:]`, the slices are different.
>
> If I were to access one of the slice backing array and mutate it, I wouldn't
> expe
It's a view in another array.
Why should they be equal? Unless the second slice is constructed by
subslicing the other as such `[:]`, the slices *are* different.
If I were to access one of the slice backing array and mutate it, I
wouldn't expect the slices to be equal anymore.
The argument that
It would be very surprising to people to use a slice as a key to map, say
[]int{1,2} and then find that using another []int{1,2} does not find that
entry. While I think it would be nice to have == on slices, I must agree
with Ian and authors that it is better left unsaid.
-Paul
On Thu, Jun 3
So that it becomes valid map inputs.
What should be hashed would be the slice/map/ref type value.
On Wednesday, June 29, 2016 at 8:38:03 PM UTC+2, Konstantin Khomoutov wrote:
>
> On Wed, 29 Jun 2016 11:20:46 -0700 (PDT)
> Chad > wrote:
>
> > And actually the same for any other similar types such
On Wed, 29 Jun 2016 11:20:46 -0700 (PDT)
Chad wrote:
> And actually the same for any other similar types such as maps...
>
>
> On Wednesday, June 29, 2016 at 8:19:45 PM UTC+2, Chad wrote:
> >
> > Just been thinking that since a slice is a "reference" type, why
> > not allow slice equality?
> >
82 matches
Mail list logo
