@Ginger the test attribute

It's not baked into the syntax like the question suggests

There's plenty of other attributes

Not that that kind of DSL would be useless, but it might be better to allow the user to make general DSLs of that sort instead of special-casing it

Kotlin go brr

I am going to not go with my previous question anymore.

I have another question that I have been thinking about.

@AlexisKing My original commnent was challenging the claim that the rules are simple, stating that the rules are only "simple" if one either ignores corner cases that would be necessary to accommodate some of the tasks for which C was designed. If one accepts the notion that the Standard is not intended to require that all implementations be suitable for all tasks that should be possible in platform-independent manner, that's fine, but...

...that would require acknowledging that the Standard's failure to accommodate a construct does not imply any judgment that the construct is illegitimate or "broken".

@ATaco oh, a wise guy, eh?

why I oughta

@supercat I don't think she's disputing that; she just wants you to talk about it in chat instead of the comments

@Ginger The original comment was specifically challenging a claim in the answer to which it was posted.

nobody's disputing that either

the content of the comment isn't the issue; the extended discussion via comments is the issue

And regardless of what one thinks the rules mean, fair point that moving to chat sooner might have been reasonable.

Consider the second sentence of N1570 6.5 paragraph 6: "If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue becomes the effective type of the object for that access and for subsequent accesses that do not modify the stored value." Will that remain the Effective Type for accesses that follow an operation that writes the object using a different type?

you lost me at "N1570 6.5 paragraph 6"

That's the location of the quoted sentence in the C11 draft.

The answer claimed the rule was simple. I quoted part of it.

that would explain it, anything regarding C instantly gets purged from my mind

If one interprets the rule as saying that Effective Types are permanent, implementation of arena allocators becomes impossible. If one interprets the rule as saying that writing an object as a new type erases the old Effective Type, neither clang nor gcc has ever implemented it correctly.

I am not qualified to discuss this lol

If one is going to truthfully claim as a "Pro" that the rules are simple, then honesty would compel recognizing as a "Con" that they make things like arena allocators impossible. If one isn't going to acknowledge that limitation, one cannot truthfully claim the rules are simple. How should I best make clear that there are two ways of making the answer correct, but as stands it is contradictory?

I'd say discuss it in chat with the post author

but then again I am neither a moderator nor a good conversationalist :b

@supercat The wording of your comments seems to frequently hinge on your opinion. You wrote “For a language to be suitable for systems programming, it must be possible to take a region of storage and make it available to code that might want to access it via any type, without regard for what types might have been used to access the storage previously. The language processed by clang and gcc when not using -fno-strict-aliasing does not accommodate that.” This is simply not true.

You justify this by writing that “Further, a language which is genuinely suitable for a task will allow the task to be performed without needless impediments. The fact that it might be barely possible to accomplish a task isn't sufficient.” I am not trying to tell you whether that perspective is justified or not; it very well may be. But it is nevertheless a subjective claim, and it invites extended arguments.

If you have a disagreement with an answer that is not a matter of the answer being straightforwardly, demonstrably wrong, it is rarely helpful to argue about it in the comments, especially if your disagreement is a controversial one. Write a different answer that explicitly calls out your disagreement, and if you’d like, leave a comment on the other answer linking to yours. This keeps the comments concise and useful, and people can vote on the answers as they wish.

I will not pretend to be able to draw a precise line on this; sometimes disagreements in comments can be productive. I prefer to avoid deleting comments if I can help it, so if you have an easily-expressed, substantive disagreement that fits into a single comment, that is usually okay. But please try to avoid escalating into an extended back-and-forth.