3 ms·

I’m having a hard time thinking of a case where replacing an existing keyword with an attribute would meaningfully improve C++. Could you maybe give an example?

jimbob45 5y ago
The idea is to give structure to a one-off idea that has been stretched to its limits. public export inline __stdcall cdecl noexcept void say_hello(std::string_view const &name); is getting a bit ridiculous (my example is preposterous, of course). It feels like there's a natural limit to how many function specifiers that the committee could reasonably include before function calls become unwieldy. Why not simply bite the bullet and create the infrastructure now to avoid issue later?
- grandmczeb 5y ago
  Couple points: 1) Are you aware of the existing C++11 attribute syntax[1]? You can replace __stdcall with [[gnu::stdcall]], for example. 2) The only function-level keywords in your example are noexcept, const, and inline. Of those, noexcept and const aren't really traditional attributes since they have significant semantic impact (e.g. on overload resolution.) 3) I don't see how the function declaration becomes less unwieldy with attributes. [1] https://en.cppreference.com/w/cpp/language/attributes https://en.cppreference.com/w/cpp/language/attributes
  - jcelerier 5y ago
    > 3) I don't see how the function declaration becomes less unwieldy with attributes. To me [[__stdcall]] [[export]] [[public]] [[inline]] void say_hello(std::string_view const &name) noexcept; looks muuuch cleaner than what we currently have ; that is, public: __stdcall export inline void say_hello(std::string_view const &name) noexcept; I don't know why, even wihtout being used to this syntax it's easier for me to parse visually. I wonder if it's because visually the return type and the attributes are at the same "level" even though they are radically different things. Though ideally it would more be like [__stdcall] [export] [public] [inline] void say_hello(std::string_view const &name) noexcept; or @__stdcall @export @public @inline void say_hello(std::string_view const &name) noexcept; or whatever the metaclasses proposal, proposed

jimbob45 5y ago

The idea is to give structure to a one-off idea that has been stretched to its limits. public export inline __stdcall cdecl noexcept void say_hello(std::string_view const &name); is getting a bit ridiculous (my example is preposterous, of course). It feels like there's a natural limit to how many function specifiers that the committee could reasonably include before function calls become unwieldy. Why not simply bite the bullet and create the infrastructure now to avoid issue later?

grandmczeb 5y ago
Couple points: 1) Are you aware of the existing C++11 attribute syntax[1]? You can replace __stdcall with [[gnu::stdcall]], for example. 2) The only function-level keywords in your example are noexcept, const, and inline. Of those, noexcept and const aren't really traditional attributes since they have significant semantic impact (e.g. on overload resolution.) 3) I don't see how the function declaration becomes less unwieldy with attributes. [1] https://en.cppreference.com/w/cpp/language/attributes https://en.cppreference.com/w/cpp/language/attributes
- jcelerier 5y ago
  > 3) I don't see how the function declaration becomes less unwieldy with attributes. To me [[__stdcall]] [[export]] [[public]] [[inline]] void say_hello(std::string_view const &name) noexcept; looks muuuch cleaner than what we currently have ; that is, public: __stdcall export inline void say_hello(std::string_view const &name) noexcept; I don't know why, even wihtout being used to this syntax it's easier for me to parse visually. I wonder if it's because visually the return type and the attributes are at the same "level" even though they are radically different things. Though ideally it would more be like [__stdcall] [export] [public] [inline] void say_hello(std::string_view const &name) noexcept; or @__stdcall @export @public @inline void say_hello(std::string_view const &name) noexcept; or whatever the metaclasses proposal, proposed