Additional suggestions when field name doesn't exist

[Nokel81]

Link to RFC: rfc-2472

Basically the gist of this improvement is adding to the list of suggestions for when a programmer types a field that does not exist in a struct.

Currently, if the field name that is typed does not exist in the struct then all fields in the struct are suggested as things that might have wanted to be typed instead. This is a wonderful feature.

I, therefore, propose that this might be even more helpful if there were some more suggestions that are presented. These being a path of field names within the struct where the fields are public to the location that the error occured and the last inner field name is equal to that of the field name typed.

How does this sound for people?

[josh]

I like this idea quite a bit.

As a nit, I think I’d suggest a smaller limit on the depth of such searches, something like 2 rather than 5. And you should clarify that this kind of search only does an exact match on the field name within a substruct, rather than an edit-distance-based search.

Also, to forestall a potential addition: I think this should remain limited to field names, not method names. In particular, because the right answer for a method name might be “you forgot to impl the appropriate trait”, and it’s more likely that you’d have identically-named methods on multiple objects for which a suggestion would be inappropriate.

[ekuber]

I like this feature request. At the very least E0609 should have a span pointing at DFA's definition (which can be added trivially now). With this feature request, it should also point at State and State::tokens, providing a structured suggestion to write i.state.tokens[0].val = 5;. That being said, making the suggestion 100% correct all the time might be tricky, without going through a full borrowck and typeck of the resulting code.

[Nokel81]

Yes I agree that this shouldn’t be for functions.

However, two things. Why such a small default depth? Second, would a levenstighn distance of 2-4 really be that bad?

[Nokel81]

I don’t think we have to check about the borrow checker because I don’t think that it currently does. This is really just helping the programer choose a possibility correct value not a completely correct item

[josh]

Seems too likely to have false positives otherwise.

[system]

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