Date: Thu, 31 Oct 2019 08:17:06 +0000
On Thu, 31 Oct 2019 at 07:57, <language.lawyer_at_[hidden]> wrote:
> I think your vector example is a bit unfortunate.
> STDlib implementers would still have to use reserved identifiers as
> template parameter names.
>
Do you know why/where from those rules have orginitated? What is the
rationale behind them?
If the rules (to have weird template parameter names in STL) come into
existence just because there was no possibility to have just one name
usable inside a class and outside, then this proposal fixes just that. And
with this proposal they are free to just one name.
After all, in 99% time the STL implementers are not using
obfuscated/distorted names for such things as "vector", "unordered_map" and
so on...
While theoretically, they could (and I think there are such cases):
namespace std {
namespace priv {
class __vector<...> {};
}
using vector = priv::__vector<...>;
}
It means that nothing prevents them from using "normal" names for template
parameters, right?
> I think your vector example is a bit unfortunate.
> STDlib implementers would still have to use reserved identifiers as
> template parameter names.
>
Do you know why/where from those rules have orginitated? What is the
rationale behind them?
If the rules (to have weird template parameter names in STL) come into
existence just because there was no possibility to have just one name
usable inside a class and outside, then this proposal fixes just that. And
with this proposal they are free to just one name.
After all, in 99% time the STL implementers are not using
obfuscated/distorted names for such things as "vector", "unordered_map" and
so on...
While theoretically, they could (and I think there are such cases):
namespace std {
namespace priv {
class __vector<...> {};
}
using vector = priv::__vector<...>;
}
It means that nothing prevents them from using "normal" names for template
parameters, right?
Received on 2019-10-31 03:19:50