-
Notifications
You must be signed in to change notification settings - Fork 252
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Can't have a member variable called value
in a @union
type
#720
Comments
This is really a problem of composition. Some type metafunctions have input names that they transform. Looking at the code printed or generated from https://cpp2.godbolt.org/z/aMrfaEvjq,
class optional {
private: std::aligned_storage_t<cpp2::max(sizeof(std::monostate), sizeof(int))> _storage {}; private: cpp2::i8 _discriminator {-1}; public: [[nodiscard]] auto is_empty() const& -> bool;
public: [[nodiscard]] auto empty() const& -> std::monostate const&;
public: [[nodiscard]] auto empty() & -> std::monostate&;
public: auto set_empty(cpp2::in<std::monostate> value) & -> void;
public: auto set_empty(auto&& ...args) & -> void;
public: [[nodiscard]] auto is_integer() const& -> bool;
public: [[nodiscard]] auto integer() const& -> int const&;
public: [[nodiscard]] auto integer() & -> int&;
public: auto set_integer(cpp2::in<int> value) & -> void;
public: auto set_integer(auto&& ...args) & -> void;
private: auto destroy() & -> void;
public: ~optional() noexcept;
public: optional() = default;
public: optional(optional const&) = delete; /* No 'that' constructor, suppress copy */
public: auto operator=(optional const&) -> void = delete;
};
class engine {
private: cpp2::u8 _value; private: constexpr engine(cpp2::in<cpp2::i64> val);
private: constexpr auto operator=(cpp2::in<cpp2::i64> val) -> engine& ;
public: [[nodiscard]] constexpr auto get_raw_value() const& -> cpp2::u8;
public: constexpr engine(engine const& that);
public: constexpr auto operator=(engine const& that) -> engine& ;
public: constexpr engine(engine&& that) noexcept;
public: constexpr auto operator=(engine&& that) noexcept -> engine& ;
public: [[nodiscard]] auto operator<=>(engine const& that) const& -> std::strong_ordering = default;
public: constexpr auto operator|=(engine const& that) & -> void;
public: constexpr auto operator&=(engine const& that) & -> void;
public: constexpr auto operator^=(engine const& that) & -> void;
public: [[nodiscard]] constexpr auto operator|(engine const& that) const& -> engine;
public: [[nodiscard]] constexpr auto operator&(engine const& that) const& -> engine;
public: [[nodiscard]] constexpr auto operator^(engine const& that) const& -> engine;
public: [[nodiscard]] constexpr auto has(engine const& that) & -> bool;
public: constexpr auto set(engine const& that) & -> void;
public: constexpr auto clear(engine const& that) & -> void;
public: static const engine off;
public: static const engine on;
public: static const engine none;
public: [[nodiscard]] auto to_string() const& -> std::string;
};
In its implementation, it uses:
Also, a local variable can't have the name of a member. A hint to prevent clashing is in my opening paragraph. For example, have
|
Thanks, this is a good learning as we're use more complex metafunctions. A metafunction generally ought to avoid name collisions with user-specified names, both for the names it generates (which should get a nice diagnostic if the user writes a collision) and the names it uses in function implementations (I like the tradition of prefix I'll take a pass at flagging those in Thanks! |
I had my misgivings, but reading the commit, it looks pretty reasonable. |
The issue is that metafunctions will want to create local variables and private helper functions, and those shouldn't conflict with any names the type author uses. Giving metafunction authors a reserved set of names they can use that doesn't conflict with "nice" user names (or with What would be the alternative... |
Nope. There's still that the chance that, at scale, |
Describe the bug
If a user defined
@union
type contains a variable calledvalue
, it fails to compile.To Reproduce
Error:
Additional context
This happens because cppfront will produce a member function
but since the parameter name is the same as a member variable, cppfront rejects the code.
I think having a member variable called
value
should be acceptable, so maybe cppfront should emit a parameter name like__value
or_Value
.The text was updated successfully, but these errors were encountered: