dfinity
Constructor stamps appearing in generated IDL
The auto-generated IDL for eg, test/run-dfinity/general-type-components.as depends on internal constructor stamps.
Also, we should probably not introduce trivial bindings for prelude declared primitive types (see Int = int below).
I notice this behaviour because the test output changed due to a change in constructor stamp.
type T_14 = Int;
type Int = int;
service A {
f : () -> () oneway;
}
hmm, T_14 should not be in the IDL, as the actor interface doesn't mention T. But if the interface does use T, what's the problem of having stamp in the type name? I don't have a concern as long as the stamps are unique.
To me it seems wrong the have the output depend on implementation details of the compiler that are likely to change. For example, I changed the prelude and the output changed from T_16 to T_14. I guess if it doesn't affect the set of implementations described by the IDL interface we might be ok. So I guess the definition of T_14 doesn't require the implementation to provide a type component named T_14 - it's really just a local type definition for use (here, no use) within the IDL.
@ggreif Can we call this one fixed in https://github.com/dfinity/motoko/pull/5013?
