Replies: 4 comments 2 replies
-
Сircumstantial evidence of my assumption is the following experiment. I tried to invoke
and compiled this code by MSVC. When
but when
|
Beta Was this translation helpful? Give feedback.
-
What you get from the IFC is what the compiler put there, so the IFC itself does not have a mechanism to put the type alias there. It is a gap in the way that the compiler (MSVC in this case) writes out the IFC - which is focused on the semantics - as most type aliases would have been evaluated by the time the IFC is written out to disk. This is also related to the issue GabrielDosReis/ipr#26 regarding how to handle type aliases. See also discussion in section 4.3 of the IPR paper |
Beta Was this translation helpful? Give feedback.
-
The compiler does not lose any type information.
That is one view, more pessimistic than I would want to bet on. I am more optimistic that modules are actually bringing implementers to work more principled diagnostic machinery. I would encourage you to continue to experiment; that is how we make progress and adoption at large.
That is certainly a dramatic statement and view that I don't share: we wouldn't be having this discussion if we didn't have Modules in the first place, and it is an example of tooling opportunity :-) |
Beta Was this translation helpful? Give feedback.
-
I have to say, I largely agree with Andrey that the loss of type alias information is a concern. I believe the IFC spec allows for this information to be encoded and therefore it's less an issue with IFC (assuming I have it correct) and more an issue with what MSVC puts into IFC. My understanding is that one of the goals of IFC is to be a universal, portable spec. Assuming that's still a goal, I think it's very worthwhile to discuss IFC independently of what MSVC is doing with it, and to separate those concerns. Which is to say that, while MSVC currently is the reference compiler for IFC, it's worthwhile to separate issues between "MSVC doesn't do this" and "IFC doesn't enable this". Similarly, it's important to keep in mind that MSVC's way of doing things isn't the only way, so just because something works for MSVC doesn't mean that it's overly feasible for all consumers of IFC to do things the same way - so it's important to have eyes with different views and experiences on this project and contributing their thoughts, concerns, ideas, etc., and give those thoughts due consideration. I think it's also well worth keeping in mind that IFC is in its infancy, and recognize that it started with MSVC and so it's naturally going to align quite well with how MSVC does things. The next goal for IFC is to expand its usefulness so that others can see good reason to adopt it - and that's up to those of us who are expending effort on IFC to work towards :) |
Beta Was this translation helpful? Give feedback.
-
Let's consider function
say_hello
declared in a module interface unit in the following wayDoes IFC provide a way to restore this pretty type for the function? The only result I managed to achieve is
Beta Was this translation helpful? Give feedback.
All reactions