You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
People like it. It would make our casting precedence much clearer since it would be the same as field/method access (our as precedence has changed twice in the last year).
I am a person and I quite like the appearance of the existing syntax, though I concede it suffers from precedence issues just like other infix operators.
I don't like it. The semantics of field access don't have much to do with the semantics of casting, and the syntax makes it look like they do. Nothing wrong with as as far as I'm concerned (I always write copious numbers of parentheses when I'm not sure about precedence in my code anyway).
Yeah, I was on the "less keywords is better" campaign the other day but I've done some doodling with code that uses 'as' and it seems to read almost strictly worse with .(type). Not sure why. Visually cluttered or something.
I agree the precedence issue on as is a bit of a problem. Or rather, the fact that as introduces a clear switch-in from the expression grammar to the type grammar, but the switch out only comes when we "finish" reading a type. For types with suffixes, this makes for an unfortunate interface point between the two grammars. Having some kind of terminator for a cast's type sub-expression would be better. I'd almost prefer as::<T>(foo) or something.
Activity
Dretch commentedon Apr 18, 2012
I am a person and I quite like the appearance of the existing syntax, though I concede it suffers from precedence issues just like other infix operators.
catamorphism commentedon Apr 19, 2012
I don't like it. The semantics of field access don't have much to do with the semantics of casting, and the syntax makes it look like they do. Nothing wrong with
asas far as I'm concerned (I always write copious numbers of parentheses when I'm not sure about precedence in my code anyway).graydon commentedon Apr 19, 2012
Yeah, I was on the "less keywords is better" campaign the other day but I've done some doodling with code that uses 'as' and it seems to read almost strictly worse with
.(type). Not sure why. Visually cluttered or something.I agree the precedence issue on
asis a bit of a problem. Or rather, the fact thatasintroduces a clear switch-in from the expression grammar to the type grammar, but the switch out only comes when we "finish" reading a type. For types with suffixes, this makes for an unfortunate interface point between the two grammars. Having some kind of terminator for a cast's type sub-expression would be better. I'd almost preferas::<T>(foo)or something.(I guess april is syntax month, eh?)
brson commentedon Apr 19, 2012
I'm convinced that
asreads nicer. There don't seem to be any firm proponents of this syntax. Closing.Auto merge of rust-lang#2231 - DrMeepster:winfred, r=RalfJung
Auto merge of rust-lang#2638 - DrMeepster:windows-condvars, r=RalfJung
Auto merge of rust-lang#2638 - DrMeepster:windows-condvars, r=RalfJung
Merge pull request rust-lang#2231 from yegeunyang/rust-lang#2069
Merge rust-lang#2231
Use anyhow::Result in xtask, add contexts
Merge rust-lang#2232
Revert rust-lang#2230
Merge pull request rust-lang#2231 from Kobzol/sync
Merge pull request rust-lang#2231 from Kobzol/sync