Yes, I meant it the same way.
Conversation
Oh. I was suggesting relevant types in the implementation without introspection in the language, but yes, you could also have the reverse, as D does. (I think compile-time introspection is nearly as bad as runtime if its usage isn't tracked in APIs, which may be the disconnect.)
2
2
Yeah, the issue with D is that you can't tell whether something is accessing type information statically or not - ie. you can't track the 'relevance' of type parameters. Tbf, I believe Rust is in the same boat thanks to specialization...
1
1
Is this a problem? Have you leaned heavily on static introspection and experienced issues? Recommend checking out youtube.com/watch?v=29h6jG.
1
1
Yup, I’ve seen this one before, it’s good. The issue with D’s introspection though is that you get template explosions similar to C++. Adding static guards on templates can help, but they are easy to forget to add.
3
1
I guess that’s orthogonal to breaking parametericity though 🤔
1
1
The benefit to parametericity is that you can rely on parameters ‘hiding’ information, and constraining the implementation. I’d like to have both introspectable and parametric parameters in my programming language.
2
3
From what I understand:
Introspectable <=> relevant <=> multiplicity == 0
Parametric <=> irrelevant <=> multiplicity > 0
1
(I think you got those flipped?)
1
1
oh woops, with the multiplicities, yes - typing on phone is tricky should be:
Introspectable <=> relevant <=> multiplicity > 0
Parametric <=> irrelevant <=> multiplicity == 0