4 ms·

Rust has an equivalent to `typename`, and it even requires it more often- the turbofish.

by Rusky 7y ago

pcwalton 7y ago
The turbofish rule is much easier to learn: just use ::<> when explicitly providing types for a call. The C++ concept of a "dependent qualified name" is a lot harder to explain. What's important isn't how often you need to help the compiler: it's how easy the rules are. The turbofish is unfortunate, but it's nowhere near as bad as typename.
- Rusky 7y ago
  But C++ could take the same route of consistency regardless of the lexer hack. The turbofish is a strict superset of `typename`, and everywhere C++ lets you skip it it could simply require it instead.
  - pcwalton 7y ago
    I don't think that's true. Consider a modified version of [1]: template<typename T> class X { void foo() { typename T::A* pa; } } The problem here is that C++ can't parse this without knowing whether T::A is a type or not. Otherwise it might be "T::A multiplied by pa". This is the lexer hack in action. Rust, by contrast, has no such limitation [2]: trait SomeTrait { type A; } struct X<T> { f: T, } impl<T> X<T> where T: SomeTrait { fn foo() { let pa: *mut T::A; } } This compiles and runs just fine with no need for a turbofish on T::A, because Rust has no lexer hack. [1]: https://en.cppreference.com/w/cpp/language/dependent_name https://en.cppreference.com/w/cpp/language/dependent_name [2]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b62ed773e7243c5352e34dabb5077738 https://play.rust-lang.org/?version=stable&mode=debug&editio...
    - Rusky 7y ago
      That's true but antiparallel to my point: C++ typename could have the same consistency as Rust's turbofish- its complicated rules are not necessitated by the lexer hack. (In a sense, the complicated rules are what enable the lexer hack.)
    - pjmlp 7y ago
      C++20 has simplified the need for typename use cases. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0634r3.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p063...

Rust has an equivalent to `typename`, and it even requires it more often- the turbofish.

by Rusky 7y ago

Rust has an equivalent to `typename`, and it even requires it more often- the turbofish.

The turbofish rule is much easier to learn: just use ::<> when explicitly providing types for a call. The C++ concept of a "dependent qualified name" is a lot harder to explain. What's important isn't how often you need to help the compiler: it's how easy the rules are. The turbofish is unfortunate, but it's nowhere near as bad as typename.

Rusky 7y ago
But C++ could take the same route of consistency regardless of the lexer hack. The turbofish is a strict superset of `typename`, and everywhere C++ lets you skip it it could simply require it instead.
- pcwalton 7y ago
  I don't think that's true. Consider a modified version of [1]: template<typename T> class X { void foo() { typename T::A* pa; } } The problem here is that C++ can't parse this without knowing whether T::A is a type or not. Otherwise it might be "T::A multiplied by pa". This is the lexer hack in action. Rust, by contrast, has no such limitation [2]: trait SomeTrait { type A; } struct X<T> { f: T, } impl<T> X<T> where T: SomeTrait { fn foo() { let pa: *mut T::A; } } This compiles and runs just fine with no need for a turbofish on T::A, because Rust has no lexer hack. [1]: https://en.cppreference.com/w/cpp/language/dependent_name https://en.cppreference.com/w/cpp/language/dependent_name [2]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b62ed773e7243c5352e34dabb5077738 https://play.rust-lang.org/?version=stable&mode=debug&editio...
  - Rusky 7y ago
    That's true but antiparallel to my point: C++ typename could have the same consistency as Rust's turbofish- its complicated rules are not necessitated by the lexer hack. (In a sense, the complicated rules are what enable the lexer hack.)
  - pjmlp 7y ago
    C++20 has simplified the need for typename use cases. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0634r3.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p063...