Hacker News Reader

Comment by bun_terminator | Hacker News Reader

If you replace your whole comment with ".", I'm just going to automatically down vote it, so the effect is worse than whatever was originally there.

These kinds of "masking" edits prevent good communication. If you want us all to disregard a comment you now totally disown, then just write an edit that prepends/appends that.

Maybe they are fine with being downvoted and just want to prevent readers wasting any further time with their comment.

Writing that in an edit is completely valid -- we're grown up enough to weigh whether to bother reading the comment then. Replacing the whole thing with just "." is not acceptable, IMO.

If they're fine with accepting the down votes either way, I still want to register my complaint, pointless as it may be in practice.

It's perfectly okay that you downvote, as that supports the goal of demoting the comment. (The effects of up/downvoting on comment ranking trumps the effect on the author's karma, IMO.) However I don't agree that pseudo-deleting is unacceptable, if for example it contained an incorrect argument and the author thinks there is no value anymore in someone reading it.

So they presumably think they were fully wrong. Wrong about what? It's often useful to know about mistaken assumptions, etc. Now all the "corrections" in the replies are harder to comprehend. Everybody's work is devalued and made harder as a result of the pseudo-delete.

I mean, take a step back and look at what you’re talking about here: a minor subthread about an incorrect argument. When I see a “.” post, I usually think “okay, nothing to see here, I can skip this”. Which in all likelihood is the best for my and everyone else's time. And I grant the OP the freedom to make that call.

In terms of UX, it probably would be better if HN allowed a commenter to “dead” their comment, including the attached subthread. People who cared could still view it with showdead, but everyone else would be saved time.

It's just mildly annoying and rare enough I want to register the breaking of an implicit norm. I don't need to take steps forward or back, or anywhere else, I just disagree with you still, for subjective reasons that should be fairly clear.

If HN decides to downvote a technical comment into oblivion that contains a minor technical oversight, I will not be part of that. And I can do whatever the fuck I want with my comments. That's what you get by (probably illegally) disabling a delete button

std::ignore doesn't work in the context of structured bindings. And even if it did, "we already have this" has never stopped the C++ committee from adding something before :)

Yes, the "skill" of the commitee to discuss some feature for a really looooooong time and then come up with a solution which is going to be (half) fixed in the next standard always astonishes mé :).

I guess with C++38 we'll get a `always_definetly_ignore_this_wothout_any_diagnostic_whatsoever`.

sure about that? It does, happen to, work on libstdc++/libc++/MS STL but it's not specified to work anywhere but std::tie. The existing practice is to cast to void.

can you show an example how? I can't find a case where std::ignore compiles inside a structured binding declaration.

https://godbolt.org/z/sjefeGvPf https://godbolt.org/z/8a7Ps4KdW

it will work for assignment/ construction, but isn't part of std c++ is what i mean. at least not yet. structured binding wont, but in the future c++ 26, _ should work there and other places

No, that's why `maybe_unused` has been needed.

Reply on news.ycombinator.com