- User Since
- Jan 30 2014, 7:28 AM (385 w, 5 d)
May 12 2021
May 5 2021
On 5/2/21 2:18 PM, Aaron Ballman via Phabricator wrote:
aaron.ballman added a comment.
FWIW, I share the concern that having a global scope for this feature instead of explicit push/pop scopes is potentially dangerous. The ergonomics of the feature make it likely the user will be applying attributes to things they had no reason to believe they were adding attributes to because this effectively means "add attributes to everything from here on out, without restriction". The fact that the user has to type *less* code to get this more dangerous behavior is a worry.
C and C++ have plenty of ways to shoot oneself in the foot.
That doesn't give us licence to add more with our extensions. I was concerned about this feature when it was first introduced, because of how incredibly easy it is to accidentally mark things you don't intend to mark. The use of very explicit scopes alleviated that concern.
Heck, pointers are expressed with a single character ('*').
Putting "using namespace std;" in some central header is a bad idea. Etc. Yet, the languages don't prevent these things,
or try to make them harder to type.
Also, I don't see how dropping 4 characters ("push") makes it any more "dangerous" (whatever dangerous means). I mean, users can already put:
Because today, push requires a pop or you get an error. So accidentally getting the scope wrong is a loud issue for the programmer to respond to. What is being proposed here can accidentally apply attributes to *anything in the TU* with no notice that you've done something wrong. What's more, it's now easy to get into that situation by omission -- if you forget to write "push", your code compiles and works fine. Then you go and add more declarations *and who knows what happens*, but sometime later the programmer will likely discover that they missed the "push". That's what I mean by "more dangerous".
Sorry for the delay responding.
May 1 2021
Apr 28 2021
Apr 22 2021
Apr 20 2021
The reason I added the #pca () syntax in D53621 https://reviews.llvm.org/D53621 was so that you could add multiple attributes to a single pushed scope in a context where you knew
exactly which scope you were adding them to (i.e., where it immediately follows a #pca push). I don't think it makes sense to use it when you aren't aware of the #pca context. There really
should never be "lots of code" between a #pca push and a #pca ().
Using a global scope is more complicated. We need to properly handle Erik's concerns about nested namespaces.
If Clang supported a "global" scope, then you would be able to just use the "#pragma clang attribute (...)" syntax when you don't want to pop. Seems like the natural solution.
Hmm, the problem I see with that is that you have to know that nobody else push-ed a #pca scope that you're inadvertently adding to.
Sure, it will work for me, though FWIW I think it's the worse option of the 3 potential solutions, and I'll be puzzled if we end with that UI.
Can anyone else speak up and state your opinions, please?
Apr 13 2021
Back in https://reviews.llvm.org/D98201 we had a larger discussion where I gave my rationale for why I thought that Clang should instead not error out when the pop is missing, so I'm not going to repeat it here.
Apr 12 2021
On 12/04/21 18:37, Artem Belevich via Phabricator wrote:
tra added a comment.
@palves -- For some reason your reply didn't make it to the tracker. I guess phabricator does not handle email replies well.
I don't understand the desire to for extra syntax -- no other push/pop pragma requires separate syntax, they simply don't error out
if the pop is missing at the end of the translation unit.
I'd argue that a missing pop is an error ( extra one should be, too), and it's those other pragmas that are not doing the right thing.
That said, I'm not inherently opposed to allowing mismatched push/pop, but I'd prefer not to, if we can.