[Idea] Turbofish replacement

language design
1

This is not an Pre-RFC yet, I’ll write one when it collects some hype and initial bikesheddings for it.

The idea here is a new syntax which does exactly what fn-call-after-turbofish does currently, but fancier. It basically looks like this.

mem::size_of(:T);
iter.collect(:Vec<_>);
make_array(:u8, :64, 0);
do_something(:T, :U, a, b);

So function call arguments can be started with optional type arguments. Type arguments are started with :, and interpreted in type context. All type arguments must be placed before any value argument, if exist.

I really like to write this RFC myself, but, well, have no idea how this feature should be called. Maybe call-with-type-args ? Um, I don’t like it.

Thoughts?

2

Not sure it is a great improvement. It feel to me you are replacing a unnatural syntax with an even more unnatural one.

In Rust, type parameter declaration has always been between angle brackets and the :T notation for this is unprecedented.

3 Likes
3
1 Like
4

@Uther :T notation idea is came from type ascription RFC, and I believe they got it from good’ol let t: T; syntax.

@mark-i-m thanks! I missed that RFC. It seems that my idea will not be needed if that RFC is accepted. But I’m not sure it will due to syntactic breakage. Angled brackets are Rust’s sin :frowning:

5

The problem is actually that you are proposing something that looks like type ascription for something that has nothing to do with type ascription.

I agree angled brackets was not a great idea but it’s too late to change the language foundations

1 Like
6

Aside from the valid points of criticism in the posts above, turbofish itself isn’t going anywhere any time soon, because it will (need to) be supported on stable for a long, long time.

Given that fact, adding anything that does something that we can already do is pointless at best, unless the ergonomicity gains are huge (which is not the case here, in fact the syntax looks rather ugly to me, but that’s subjective). More likely it will be actively harmful as now there would be 2 ways baked into the language that do the same thing, which increases the learning curve and moves us closer to the engineering hell that is C++.

As a final minor note, fanciness is not an argument in favor of a feature, it’s almost always an argument against. The reason for this is that fanciness correlates strongly with complexity: ever seen a fancy piece of tech that was also simple? Complexity then, is something best seen as something humans both spend and have a budget for. That is, it’s modeled more properly more like money (i.e. we have a finite amount of it at any given moment, and it’s unwise to spend more than you have) than e.g. air (which we also consume, but is free in every sense of the word and essentially not in any kind of short supply, at least for now).

2 Likes
7

For one, I'm strongly against any new syntax that's explicitly and completely redundant with existing ones.

That question aside, I think this is actually less representative/evocative of its function. Generic type arguments come in angle brackets on the declaration side. Therefore it's nice that they also go in angle brackets at the call site. The proposed syntax would break the "things that are similar should look similar" principle, therefore it's probably more confusing than it would help with clarity.

8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.