See if Node::start_position and Node::end_position can be turned from Option<T> to just T

[Kampfkarren]

It feels really unergonomic to be unwrapping every single call.

[Kampfkarren]

Trying to resolve this gives issues when dealing with Vec<T>--should it have a Node implementation in the first place?

Should Node be split in the same way PartialOrd/Ord are?

[Kampfkarren]

The way syn does it (#23) is it exposes a Spanned trait which is implemented for everything that implements ToTokens.

While ToTokens is not implemented on Vec<T>, it is implemented on Option<T>. Not sure what it reports as its position when its None.

[tomprince]

Looking at the implementation in proc_macro2, it looks like they have a dummy file, that is used for spans that aren't tied to a specific place.

[Kampfkarren]

That's strange, I wonder if that's actually better than Option! It's more ergonomic, but it feels like it would have the same problems as something like null.

[tomprince]

I've not used it just looked at the code[1], but it gets represented as something like <unspecifed>:0:0. In syn`, one of the things spans gets used for is things like macro expansion, and saying where textually names are resolved, so it isn't entirely about tracking position information, so the tradeoffs might be different there.

That said, if you are doing code transforms, it might be useful to have a way to track in the ast whether a token came from user code, or was synthesized by the tool.

[1] I've only looked at the code when not being used as a proc-macro (i.e. the fallback code in proc-macro2), so the representation in the compile might be different.