Comment author: @trefis

Jacques said:

Typically, this information is only useful when you want to know what
the source code looked like, but comes in the way for program
transformations.
In general having to recurse on the syntax tree just to discard
information doesn't seem the right way to me.

Alain said:

As for keeping extras vs replacing them with proper nodes,
it would be useful to have concrete examples of which pattern matching
would actually become more complex with proper nodes. Typedtree is
being used more and more by external tools (through .cmt files), and
having something as simple as possible (and close to the Parsetree)
also has some value. If this amounts to adding 10 lines of code to
traverse (current) extra nodes, it's worth the change, I'd say.

Personally I tend do agree with Alain on that one.
I will do an implementation with the extra constructors added to the expression type that way we can see how much code change is needed.

Comment author: @garrigue

No bug here.

FTR local opens in expressions are now actual an actual node, not stored in the extra field.
That is still not the case for patterns.

Nothing happened on the side of type constraints.

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

This is a bit of a meta-issue on code-cleanliness. I also agree with @alainfrisch and @trefis that making parsetree and typedtree completely mirrored, without any extra nodes, would be nice. It's just a matter of someone doing it.