Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch to go's casting syntax #2231

Closed
brson opened this issue Apr 17, 2012 · 4 comments
Closed

Switch to go's casting syntax #2231

brson opened this issue Apr 17, 2012 · 4 comments
Labels
A-grammar Area: The grammar of Rust

Comments

@brson
Copy link
Contributor

brson commented Apr 17, 2012

Go does:

x.(type)

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).

@Dretch
Copy link
Contributor

Dretch commented 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
Copy link
Contributor

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).

@graydon
Copy link
Contributor

graydon commented 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 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.

(I guess april is syntax month, eh?)

@brson
Copy link
Contributor Author

brson commented Apr 19, 2012

I'm convinced that as reads nicer. There don't seem to be any firm proponents of this syntax. Closing.

@brson brson closed this as completed Apr 19, 2012
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
Windows thread support: Part 1

This PR adds support for threads on Windows.
RalfJung pushed a commit to RalfJung/rust that referenced this issue Nov 6, 2022
Implement condvars for Windows

Adds 3 shims for Windows: `SleepConditionVariableSRW`, `WakeConditionVariable`, `WakeAllConditionVariable` to add support for condvars (which fixes rust-lang#2628).

Salvaged from what was removed from rust-lang#2231
RalfJung pushed a commit to RalfJung/rust that referenced this issue Nov 15, 2022
Implement condvars for Windows

Adds 3 shims for Windows: `SleepConditionVariableSRW`, `WakeConditionVariable`, `WakeAllConditionVariable` to add support for condvars (which fixes rust-lang#2628).

Salvaged from what was removed from rust-lang#2231
Aaron1011 pushed a commit to Aaron1011/rust that referenced this issue Jan 6, 2023
Implement condvars for Windows

Adds 3 shims for Windows: `SleepConditionVariableSRW`, `WakeConditionVariable`, `WakeAllConditionVariable` to add support for condvars (which fixes rust-lang#2628).

Salvaged from what was removed from rust-lang#2231
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-grammar Area: The grammar of Rust
Projects
None yet
Development

No branches or pull requests

4 participants