Daniel Gibson:
> Really? Than that definition from the language docs is inaccurate.
This compiles, here n is known at run-time only:
void main(string[] args) {
const int n = args.length;
}
This compiles, but I think it's a bug:
void main(string[] args) {
enum int n = args.length;
}
This shows that there is a problem:
template Foo(int n) {
}
void main(string[] args) {
enum int n = args.length;
alias Foo!(n) _;
}
> I know what you meant - but my point is that anon. enums make sense (I
> guess we agree on that one) and that allowing implicit casting to int
> for them and not for named enums seems inconsistent.
The real inconstancy is using 'enum' for them both in the first place. They are
conceptually two different things. It looks inconsistent if you think of them
as similar things.
But even if you like to think of them as the same thing, you may think of my
proposal as a way to enforce more strong typing, to remove a subset of the
allowed behaviours of one subclass of those enum thinghies that you think are
all the same thing. So you may see it as an inconstancy introduced on purpose
to remove some risky behaviours. D has introduced some other of such
'inconsistencies' (compared to a uniform C behaviour) where they help disallow
some behaviours that are regarded as negative.
> Of course disallowing implicit casting for anon. enums is not really an
> options (how should that even work.. maybe "cast(enum:int)foo" or
> something like that..)
Right.
>so IMHO a reasonable solution is keeping it the way it is.
In my opinion (and probably in the opinion of the people that are designing
C++x0) this is not a good enough solution, because it's a little error-prone.
Bye,
bearophile
