Should we hide unstable features better?

[bluss]

error: expected type, found `2`
 --> <anon>:3:37
  |
3 |     ::std::convert::From:from(idx < 2);
  |                                     ^

error: expected one of `!`, `->`, `::`, `;`, or `}`, found `)`
 --> <anon>:3:38
  |
3 |     ::std::convert::From:from(idx < 2);
  |                                      ^

error: type ascription is experimental (see issue #23416)
 --> <anon>:3:5
  |
3 |     ::std::convert::From:from(idx < 2);
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

Computers are always so literal, aren’t they? Either way, the error is really syntax error, not that we wanted to use some unrelated feature.

This reminds me of another compiler (ahem gcc) which when you forgot a closing brace, it dutifully told you for each following function in the file, that nested functions was a gcc extension.

The extensions (in gcc’s case) and unstable features (in rustc’s case) get in the way of the users’ normal interaction with the stable (or standardized) language.

It’s a confusion for new users and a papercut for us established rusties.

[leonardo]

error: type ascription is experimental

Receiving that error message when you forget one “:” is a quite common occurrence for me. I guess that type ascription will be used only rarely, so I think using a bit longer syntax for it is acceptable.

[cuviper]

Type ascription may eventually be a stable feature though, so I think it’s worth thinking how to improve this error message now. Can that error handler walk back to the single : and offer a hint there?

[StefanoD]

Submit an issue, please.

[brson]

@bluss This is certainly a confusing error, and the error itself could be better for sure. But one thing we could do to make this particular class of future-feature errors go away is to change the parser’s behavior on the stable channel so it just doesn’t parse these things at all, and there’s no need to attempt to parse it since it’s impossible for the user to actually use the feature. It would definitely make this case less confusing. We would need to expand the test suite capabilities to cover the stable parsing mode.

[cuviper]

Would the parsing stage know whether the bootstrap key and #[feature] flags are in effect?

[brson]

Yes, the parser can know whether unstable features are allowed to be used at all, via either the stable release channel or the bootstrap key.

[vi0]

error: type ascription is experimental (see issue #23416) –> :3:5 3 | ::std::convert::From:from(idx < 2); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Should it point to the colon, not the whole line?



    3 |     ::std::convert::From:from(idx < 2);
      |                         ^

[bluss]

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