You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Back then, we had TypeTag (=AbsTypeTag now) and ConcreteTypeTag (=TypeTag now), and people used "TypeTag" context bounds everywhere (I guess that's because if everyone mentions "type tags", then your knee jerk reaction is to write TypeTag without even suspecting that there's ConcreteTypeTag). As a result, things like this could happen (and actually happened): #5884. So we decided to make concrete type tags the default choice to prevent confusion.
However for macros the situation is exactly the opposite. As you rightly mentioned, AbsTypeTags are most often the right choice. At first, I thought that this won't be a problem, because people who write macros will be more experienced than people who just want to migrate from manifests. However on a second thought I think we fall into the same problem - encouraging people to shoot off their feet (and the "more experienced" argument is just an excuse).
I think we should simply prohibit TypeTags in macro impl context bounds, leaving AbsTypeTag as the only supported bound. If a macro really-really needs concreteness guarantees (and, as your example above shows, that would be an exceptional case), then this verification can be easily performed inside the macro body.
The text was updated successfully, but these errors were encountered:
Back then, we had TypeTag (=AbsTypeTag now) and ConcreteTypeTag (=TypeTag now), and people used "TypeTag" context bounds everywhere (I guess that's because if everyone mentions "type tags", then your knee jerk reaction is to write TypeTag without even suspecting that there's ConcreteTypeTag). As a result, things like this could happen (and actually happened): #5884. So we decided to make concrete type tags the default choice to prevent confusion.
However for macros the situation is exactly the opposite. As you rightly mentioned, AbsTypeTags are most often the right choice. At first, I thought that this won't be a problem, because people who write macros will be more experienced than people who just want to migrate from manifests. However on a second thought I think we fall into the same problem - encouraging people to shoot off their feet (and the "more experienced" argument is just an excuse).
I think we should simply prohibit TypeTags in macro impl context bounds, leaving AbsTypeTag as the only supported bound. If a macro really-really needs concreteness guarantees (and, as your example above shows, that would be an exceptional case), then this verification can be easily performed inside the macro body.
The text was updated successfully, but these errors were encountered: