A simulation-only function like Std.Random.DrawRandomInt is annotated with a @Config attribute (in this case, @Config(Unrestricted)) to indicate that it shouldn't be available unless a suitable profile has been selected. Such functions are filtered out quite early in the compilation process (AST probably?) with the result that the design time error is "unresolved name". It would be much more user friendly to resolve the name and then explain why it's not available. Besides improving the error experience, this would make features like Quick Info and Go-to-Def available.
There's a substantial wrinkle: we don't use config only to remove unavailable functionality. Sometimes, multiple implementations are provided - for example, a simple one for Base profile and a more efficient one for Adaptive. If multiple implementations have unsatisfied config attributes, it's much less clear which to resolve in the editor.
One direction to consider might be to introduce an internal concept of stub/skeleton/declaration-only signatures without bodies. This would retain the benefit of not having to compile the implementation, while also keeping it available at design time.
In the interim, we might be able to hack the multiple implementations case by having an unconditionally available function that calls one of multiple conditionally available (i.e. depending on the profile) inner functions.
A simulation-only function like
Std.Random.DrawRandomIntis annotated with a@Configattribute (in this case,@Config(Unrestricted)) to indicate that it shouldn't be available unless a suitable profile has been selected. Such functions are filtered out quite early in the compilation process (AST probably?) with the result that the design time error is "unresolved name". It would be much more user friendly to resolve the name and then explain why it's not available. Besides improving the error experience, this would make features like Quick Info and Go-to-Def available.There's a substantial wrinkle: we don't use config only to remove unavailable functionality. Sometimes, multiple implementations are provided - for example, a simple one for Base profile and a more efficient one for Adaptive. If multiple implementations have unsatisfied config attributes, it's much less clear which to resolve in the editor.
One direction to consider might be to introduce an internal concept of stub/skeleton/declaration-only signatures without bodies. This would retain the benefit of not having to compile the implementation, while also keeping it available at design time.
In the interim, we might be able to hack the multiple implementations case by having an unconditionally available function that calls one of multiple conditionally available (i.e. depending on the profile) inner functions.