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

Implement type 'any' and alt-type #61

Closed
froystig opened this issue Jun 23, 2010 · 4 comments
Closed

Implement type 'any' and alt-type #61

froystig opened this issue Jun 23, 2010 · 4 comments
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) A-type-system Area: Type system

Comments

@froystig
Copy link
Contributor

Similar to alt but branches on the actual type of its any-typed head expression rather than the value. Implement in full --- doesn't even parse at the moment. See manual. Should also include the 'any' type and how to inject/extract values from it.

@graydon
Copy link
Contributor

graydon commented Jan 27, 2011

Shifted to rustc

@brson
Copy link
Contributor

brson commented Oct 12, 2011

To really make this useful now it would need to have variations for the different kinds, any~, any@, any&, or such.

@brson
Copy link
Contributor

brson commented Oct 29, 2011

Even though we haven't had a pressing need for this I think it could be useful in error handling. For example an error(any) type is more composable than error(T). And given that fail essentially takes type any, it would provide a nice way to perform a 'try' operation in another task and return an error(any~) of the fail value to the original task.

@catamorphism
Copy link
Contributor

#1498 -- as well as traits/impls -- supersede this, we agreed. Closing.

Manishearth added a commit to Manishearth/rust that referenced this issue Jul 10, 2015
…bnik

So I have tried to improve the rustbook engine:

- The sidebar now looks a lot more like gitbook (I thinks it cleaner)
- Added the Open Sans font, in my opinion more readable for prolonged periods of time
- Changed the style for code blocks a little

I encountered 1 problem. In `build.rs` I added this google font url (I commented out the non-relevant parts for clarity) 

```rust
let rustdoc_args: &[String] = &[
    //"".to_string(),
    //preprocessed_path.display().to_string(),
    //format!("-o{}", out_path.display()),
    //format!("--html-before-content={}", prelude.display()),
    //format!("--html-after-content={}", postlude.display()),
    //format!("--markdown-playground-url=http://play.rust-lang.org"),
    //format!("--markdown-css={}", item.path_to_root.join("rust-book.css").display()),
    format!("--markdown-css=http://fonts.googleapis.com/css?family=Open+Sans:400italic,700italic,400,700"),
    //"--markdown-no-toc".to_string(),
];
``` 
As you can see, I had to escape `=` with `&rust-lang#61;` because the string would get truncated if I didn't. Is that normal behaviour? Is that for security measures? If it is, isn't it a little weak if you can circumvent it by escaped characters? I don't know the reason behind, but I thought it was at least worth mentioning :)

Take your time for this PR, I still want to add multiple improvements:

- Like gitbook, possibility to change font by user
- Put `css` and `js` in their respective files (not hardcoded in rust)
- button to hide sidebar
- ...

So I'm not in a hurry to get this merged ;) But if you think it's good enough to be merged, go ahead. I will make another PR when I have other improvements.

In the image below is a screen of the improvements

![rustbook](https://cloud.githubusercontent.com/assets/7647338/8105345/bf545c74-1038-11e5-962e-b04ebfaf8257.png)
bors added a commit that referenced this issue Jul 27, 2015
So I have tried to improve the rustbook engine:

- The sidebar now looks a lot more like gitbook (I thinks it cleaner)
- Added the Open Sans font, in my opinion more readable for prolonged periods of time
- Changed the style for code blocks a little

I encountered 1 problem. In `build.rs` I added this google font url (I commented out the non-relevant parts for clarity) 

```rust
let rustdoc_args: &[String] = &[
    //"".to_string(),
    //preprocessed_path.display().to_string(),
    //format!("-o{}", out_path.display()),
    //format!("--html-before-content={}", prelude.display()),
    //format!("--html-after-content={}", postlude.display()),
    //format!("--markdown-playground-url=http://play.rust-lang.org"),
    //format!("--markdown-css={}", item.path_to_root.join("rust-book.css").display()),
    format!("--markdown-css=http://fonts.googleapis.com/css?family=Open+Sans:400italic,700italic,400,700"),
    //"--markdown-no-toc".to_string(),
];
``` 
As you can see, I had to escape `=` with `=` because the string would get truncated if I didn't. Is that normal behaviour? Is that for security measures? If it is, isn't it a little weak if you can circumvent it by escaped characters? I don't know the reason behind, but I thought it was at least worth mentioning :)

Take your time for this PR, I still want to add multiple improvements:

- Like gitbook, possibility to change font by user
- Put `css` and `js` in their respective files (not hardcoded in rust)
- button to hide sidebar
- ...

So I'm not in a hurry to get this merged ;) But if you think it's good enough to be merged, go ahead. I will make another PR when I have other improvements.

In the image below is a screen of the improvements

![rustbook](https://cloud.githubusercontent.com/assets/7647338/8105345/bf545c74-1038-11e5-962e-b04ebfaf8257.png)
dlrobertson pushed a commit to dlrobertson/rust that referenced this issue Nov 29, 2018
Document closure to fn coercion feature
eddyb pushed a commit to eddyb/rust that referenced this issue Jun 30, 2020
antoyo added a commit to antoyo/rust that referenced this issue Aug 14, 2021
bors pushed a commit to rust-lang-ci/rust that referenced this issue Oct 1, 2021
djtech-dev pushed a commit to djtech-dev/rust that referenced this issue Dec 9, 2021
Revert "Bind Symbol to the engine using lifetime not Rc"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) A-type-system Area: Type system
Projects
None yet
Development

No branches or pull requests

4 participants