- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
RFC: Add x as <type>
syntax for conversion.
#15818
Conversation
IMHO, |
The constructor can have additional behaviour that may not be desired, i.e. @tkelman I made a simple doctest in the manual. What tests would you like to see? Testing behaviour (i.e. same as convert) or precedence? |
I like this, because I think it could be generalized well to other places where convert would be useful, such as return types : and argument types : |
Should be tested as thoroughly as possible without making the tests noticeably slower. Usage, behavior, different parsing contexts, etc. Like any new feature. |
The current function
-erik On Sun, Apr 10, 2016 at 5:43 AM, Tony Kelman notifications@github.com
Erik Schnetter schnetter@gmail.com |
I'm not convinced of the need for a new keyword here. In the vast majority of cases, |
I think we're finding that this is not true, and slowing backing off on that experiment (and revising the call -> convert rule). The main benefit I still see here is that it adds a way to make it easy to convert early to the intended type (without worrying if call and convert happen to be the same) and making it clear what the author intended. Plus, making sure there aren't unnecessary types around can make it easier on the compiler so it can do it's job faster and get out of the way. |
@vtjnash, aren't most conversions in practice from one numeric type to another, or from one collection type to another? And in these cases |
Yes. But my point is that conflating the concepts works pretty well ... until it doesn't, and then it can be nice to have an explicit syntax instead of relying on the implicit form. ref #15120 |
I very much like the @vtjnash While using the Including magic like |
Not convinced this is an accurate statement. Most people are already familiar with the idea of the "compiled type". The thing that is more alien to new developpers is probably the If your issue is with the
(Taken from "Type seperation & code bloat: dispatch vs compile type." ...But I honestly do not hate the "as" notation. |
In function signatures, this syntax would work: f(n::Integer=>Int) = 2n + 1 Which would be shorthand for this pair of definitions: f(n::Integer) = f(Int(n))
f(n::Int) = 2n + 1 The syntax isn't applicable in other contexts, but in those cases, I feel like calling |
This sounds similar to what |
I think it would be nice if we can do this more generally, instead of just making it syntax sugar for as{T}(::Type{T}, f, xs...) = convert(T, f(xs...)) that can be overloaded to allow things like Kind of like fused broadcast. It's an optimization in most cases and could affect observable behaviour in some cases, but only when that makes sense. A similar thing can probably be done for local variables with type annotations. Then someone can do |
Feels very similar do the |
I was thinking about ways to (say) get the first 10 graphemes of a string as a |
FWIW, I just came across the Swift as semantics today, which include:
Note that these are the only two versions, i.e. you can only do a weak (Nullable) or forceful convert. I kind of like this distinction, because there's been quite a few back and forths on our own f(x; optional_kwarg::Nullable{Int}=Nullable{Int}()) be called like f(x; optional_kwarg=1) Anyway, just a few thoughts here. |
With this PR:
(12 as Float64) === 12.0
Very similar to what Rust does.
I copied what was done with
in
on the parser side but that might be the wrong place for it?Would people like this? I certainly would find it a useful syntactic sugaring. I looked for previous proposals for
convert
syntax but couldn't find any, but I apologize if this has already been discussed.