On 09/05/2012 8:32 PM, Niko Matsakis wrote:
The `as` operator is annoying for a number of reasons:
- the precedence is non-obvious and hard to get right (3 + 4 as uint)
- it introduces a weird ambiguity around type parameters (`3 as foo::<T>`)
Recently Go's syntax was proposed as a remedy (`3.(int)`), but rejected
because it looked weird (which it does).
I concur it'd be nice to get rid of the current form.
I'm a little nervous about what you're proposing here. I think enums can
probably be done with a sys::enum_value<T> intrinsic that fails to
compile on non-enums. Or something involving the reflection interface
I'm currently building. I don't think this part is a blocker.
The bigger concern I have is moving from an expression that's reasonably
a const-expr to what looks like a function call. A few cases stand out
(say "((0xff << 10) | 'z') as uint" or such) though possibly they can be
solved by cramming more temporary consts and/or type-literal suffixes in.
More generally it raises my concern about const-exprs as functions.
Iintrinsics probably already have this problem; we won't constant-fold
through them. It'll get particularly bad if we move (as you and I have
discussed) to using the operator overload system for all the normal
arithmetic forms; 'as' is then just a special case of "how do we get
constant folding through user-defined expressions"? In C++0x they added
"constexpr" as a qualifier for functions. I could imagine supporting
'const fn foo' in rust as a way of indicating a fn that can be used in a
const-expr, at least when applied to const-expr arguments.
(nb: even if const-folding through user expressions wind up
turing-complete, it's not the same as "turing complete type system", and
I'm much less concerned about it. We already support the concept of
invoking arbitrary code at compile time, due to the plan for syntax
extensions and attribute extensions. My objection to making the _type_
system turing complete is that the encoding ,"evaluation" model,
type-system-of-types and diagnostic facilities are very very crude, so
it's a bad place to enrich to that level.)
So uh .. in the specific case of 'as' I'm not deeply worried what it
changes to, if anything. But I think we need to look at constant folding
first before making a move on it.
Sorry if that seems like derailing your goal!
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
