Rework generic paths for associated functions: T::function()

[brendanzab]

This issue formalizes @pcwalton's RFC on the mailing list. This was also discussed in the 2013-05-14 meeting and in #6087. Steps towards this have already been made in #6462.

Whilst this is not a high priority change at the moment (understandably there are far bigger fish to fry), this is a semi-common question on the IRC and I think it's good if we have some place to redirect questions to.

Instead of the current:

Real::pi::<float>()

this change would allow you to do:

float::pi()

or

type T = float;
T::pi()

This could also allow for neat things like a generic SizeOf trait: T::size_of(), which is far nicer than the current size_of::<T>(). Or maybe there could be an Init trait for default initializers: T::init().

[brendanzab]

See also: #5635

[brendanzab]

See also: [rust-dev] Calling static methods on type parameters?

[brendanzab]

Something that needs consideration would be how to handle more complex types. Assuming there was a SizeOf trait, an example would be: (~Option<float>)::size_of()?

[nikomatsakis]

The approach to invoking size_of as described in @pnkfelix's blog post would be:

use impl foo = SizeOf for ~Option<float>;
...
foo::size_of();

[brendanzab]

@nikomatsakis Ah, I didn't realize it was another case of the use impl technique that has been mentioned before.

[pnkfelix]

I have been wanting to work on this, but it may be too big a task for me to take on immediately. If I decide that I can indeed tackle it, I will assign this issue to myself.

[brendanzab]

@pnkfelix Unfortunately I was having a little trouble following your blog post as the issue is pretty involved (that's no slight against it though). Unfortunately I come from a position of ignorance, without a full understanding of the moving pieces involved.

Which approach do you favour? Personally, from an ignorant user perspective, I think something like (~Option<float>)::size_of() would be highly intuitive, but in an in-depth discussion with @nikomatsakis yesterday on IRC, apparently there are key logical reasons why that can't be done.

At least we can agree that the current way of doing things must be improved (eg. #6898).

[brendanzab]

@pnkfelix for reference, here is the log of our discussion: https://botbot.me/mozilla/rust/msg/3557231/

[nikomatsakis]

@bjz I didn't meant to give the impression it can't be done... just that there are situations that syntax can't express, and other considerations as well. I tried to explain those considerations as well as I could in these blog posts

http://www.smallcultfollowing.com/babysteps/blog/2013/04/02/associated-items/
http://www.smallcultfollowing.com/babysteps/blog/2013/04/03/associated-items-continued/

[pnkfelix]

@bjz The context of the IRC log doesn't tell me how deeply you all got into this, so forgive me if I cover ground you've already covered. Also, I'm working mostly from memory here, and I may well get some of the details wrong.

Syntax like (~Option<float>)::size_of() turns our notion of a path from a sequence of identifiers into a tree structure (because the tree-structured type-expressions will appear as sub-components of a path), and I'm very hesitant to do that in the short term: it would be a big change to a core component. (This is discussed in my blog post under the heading "Rust type expressions do not naturally fit into Rust path expressions.")

So that's why my proposal factors out ~Option<float> to a identifier, a token that can be referenced in the existing path syntax. That binding is expressed by the use impl item.

A goal I was trying to achieve in my proposal was "minimize changes to the core of the syntax, and hopefully the compiler too." My usual justification for that sort of goal when it comes to adding features like this goes something like "Longer term, after we gather experience with an implementation that can express these general associated items (even if it requires some local syntactic gymnastics), we'll be in a better place to evaluate more expressive options."

But a problem with the above justification is that if the syntax is poorly chosen now, then that may adversely affect the body of code that uses associated items that would be used as the basis for coming up with a better syntax. Because of this problem, I plan to consider any reasonable suggestions for alternative syntax that are offered up.

For example, if you can present an argument for why tree-structured path syntax will pay for itself, or is inevitable, then maybe that would help us reconsider whether (~Option<float>)::size_of() is viable. But for right now, I do not think it is sufficient to say that the syntax would be highly intuitive, because it does not account for how doing this might complicate (or adversely interact with) other portions of the syntax and/or compiler, which may inject more confusion and non-intuitive behavior.

More concretely: You may need to even incorporate issues like how the macro-expander works. I do not know off-hand whether our term-rewriting macro_rules! can deconstruct and/or introduce new paths, or if paths are treated as atomic entities in that context. But either way, a change to the path syntax will affect either the definition of such macros or how one uses them.

[pnkfelix]

But either way, a change to the path syntax will affect either the definition of such macros or how one uses them.

This may have been an over-statement on my part. (There may be a way to generalize the path syntax to allow tree structure that does not break old macro definitions.) But I am not certain either way, and in any case I think there would be push-back to putting tree structure into paths.

[brendanzab]

@pnkfelix Thanks for the responses! Could you re-explain what you mean by 'tree structure in paths'? And why is this considered undesirable?

[brendanzab]

I guess one of the other issues I have with the current way of accessing associated functions via the trait is the asymmetry with method calls. That is, 2f.sqrt() or "hiya".len() is accessed with respect to the implementing type, where Real::pi() or Zero::zero() is not. I do however understand that those are trivial examples, and there are far more complex edge cases to consider.