_ as value when deleting from a map
Keith Rarick
m[k] = _, false
to delete from a map. In this case, _ could be defined as a zero value
of the appropriate type, though as an optimization the compiler could
just delete the item without bothering to construct the value.
kr
Rob 'Commander' Pike
variable, there needs to be an actual value. You're right that the
meaning could be 'the zero value', although that's a new meaning of
the blank identifier.
Interesting idea, though.
-rob
Rob 'Commander' Pike
map[k] = _
That's yet another meaning of _, of course. It's cute, too cute.
Map deletion is important but rare enough that it doesn't need
fine-tuning syntactically.
-rob
Krzysztof Kowalczyk
del map[k]
like in Python?
The intent of del map[k] is clearer than map[k] = _, false, for
beginners and experts alike.
I would argue that it would help readability because overloading
assignment for delete is confusing and that icky feeling doesn't go
away even if you know the idiom.
-- kjk
Russ Cox
> beginners and experts alike.
If you know about x, ok = m[k] and what it means for ok to be false,
then m[k] = x, false should be plenty clear. If you don't know
about that, well you should, beginner and expert alike.
Russ
Popog
> If we're going crazy (which we're not) we could reduce it to
>
> map[k] = _
>
> That's yet another meaning of _, of course. It's cute, too cute.
channel. Reading from "/dev/null/' (which is what I associate _ with)
is an immediate EOF, so it makes sense from that perspective.
Otherwise I agree with "delete(map[k])" or "remove(map[k])". It makes
much more sense and keeps the language more orthogonal. If you want
conditional removal, use an if statement.
Jessta
That would have to make delete() or remove() built-ins which would
make it impossible to have a delete() and remove() function as part of
your package, there are already enough built-ins.
I like map[k] = _ but it would be confusing because you couldn't
assign '_' to anything else.
The current version makes much more sense.
if x, ok = m[k] then semantically m[k] is representing two values of
type T and bool.
it's similar to
x,ok = OfTypeT,true
so mk[k]=x,false is similar to:
T,bool = x,false
- jessta
--
=====================
http://jessta.id.au
Scott Lawrence
> I actually like this to a degree. Maybe even have "c <- _" close a
> channel. Reading from "/dev/null/' (which is what I associate _ with)
> is an immediate EOF, so it makes sense from that perspective.
for _, I'd like to see a null type. struct{} is too hard to type when
I don't intent to use the data.
type T struct{}
func (T) SomeMethod() (s string, e os.Error) { /* stuff */ }
(Tell me if I missed the good way to do that.)
--
Scott Lawrence
Marcin 'Qrczak' Kowalczyk
'm[k] = x, false' forces the programmer to provide a value for the
map, while deleting a map element conceptually does not depend on any
value for the map. Forcing to provide an argument which is known to be
ignored is silly.
--
Marcin Kowalczyk
Krzysztof Kowalczyk
I like x, ok = m[k]. Even though it's not an idiom used in other
languages, it has good properties:
1. it's pragmatic i.e. it makes code shorter and it elegantly
addresses an issue I often bump into when working with dicts in e.g.
python where I have to split my code into checking if element exists
in a dict and accessing it. if's abound in that case.
2. it's still an assignment. Once I know about multi-value return, I
have no problem understanding what that particular multi-value
assignment does. No surprises here.
m[k] = _, false, on the other hand:
1. Is not pragmatic. It forces me to provide a value (_) that is
ignored. It's intent is more obscure than e.g. del m[k] and it's not
shorter than del m[k]
2. it overloads the meaning of assignment to be delete. It doesn't
really make sense that a syntax that in every other context means
"assign" in this particular context means "delete". It is a surprise.
Mental context switch is needed to parse it differently in that
context.
The only (dubious) thing it has going for it is to preserve symmetry of:
x, ok = m[k] <=> m[k] = _, false
but to me it's a superficial similarity and not worth sacrificing
points 1) and 2).
Even m[k] = _ would be better because I could convince myself a little
more that assigning a non-existent value is like delete (and it is
shorter). I guess what bothers me most in that syntax is that it does
look like an assignment hence my primary way of interpreting it is as
an assignment and from that perspective it doesn't make sense.
I'm not convinced by "you should just learn how it works" argument
(I'm paraphrasing, maybe unfairly). I know what that syntax does
because I've read the tutorial and I've written some code. It's not
that I can't learn it or use it, it's that after I learned it and used
it, it doesn't make conceptual sense to me and I believe del m[k] (or
m[k] = _) are better from pragmatic and conceptual point of view.
-- kjk
jimmy frasche
m[k] = x, x > 1