-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Figure out a different way to allow crate-level and directory-level modules #1277
Comments
How about simply making it an attribute?
|
I'm ok with an attribute, but I recall that last time I discussed it with pcwalton we concluded this should be a proper part of the language. |
I'm actually ok with the structure we have now. It's a little confusing, but not deeply so, and I think most other forms of additional indirection will just make the confusion worse. |
I think the way directory mods work now is fine and isn't likely to be surprising. I've seen the implicit crate mod be confusing several times now. rovar on IRC described seeing a "multiple 'main' function" error, which happens when you have file A potential way to solve this is by removing the distinction between .rc and .rs files. There are very few differences between the two and combining them would eliminate more than one source of confusion. I think that if you allow filesystem-based mod declarations like those in .rc files in .rs files then .rc is redundant. |
I think the conclusion I drew there is not quite true. |
I'm warming to #2176. I'd close this as redundant with it, and just do that. |
Closing, see #2176. |
Implement a couple of portable simd intrinsics
* Restore `rintf*` intrinsics * Remove negative tests * Restore `nearbyintf*` intrinsics * Remove negative tests * Add tests for `rintf*` and `nearbyintf*` * Require `diff` to be [0, 0.5]
The solution implemented in #1072 causes lots of confusion. Let's revert it and implement something else.
The text was updated successfully, but these errors were encountered: