3 ms·
Excited to see user defined literals: > In Ada 2022, you can define string, integer, or real literals for your types. The compiler will convert such literals t
by MaxLeiter 4y ago
Excited to see user defined literals:
> In Ada 2022, you can define string, integer, or real literals for your types. The compiler will convert such literals to your type at run time using a function you provide.
The example is fun, showing type concatenation in Ada à la JavaScript https://learn.adacore.com/courses/whats-new-in-ada-2022/chapters/user_defined_literals.html#turn-ada-into-javascript https://learn.adacore.com/courses/whats-new-in-ada-2022/chap...
- donatj 4y agoThis just seems dangerous, hard to read, and the total opposite of what Ada is supposed to be about.
- foerbert 4y agoI'm not sure about that. Dangerous, I can see it if it's not implemented reasonably. I'll admit to being less than a stellar ARM reader so I can't say for sure, but I'd bet this was well-considered when it was added. Considering these are literals conversions should be check-able at compile time with some reasonable limitations, and I assume those were added. If I'm wrong though, do let me know. Hard to read? Maybe, but not really? It feels like a 'modern' feature to me in the sense that back in the old days it may have been a little too opaque and required a step more than is ideal to see through it, but with modern editor facilities it seems easily fine. And I don't think it's as bad as tagged types can be in that respect, so I don't see this being a problem. And it will enable some much nicer to use interfaces for libraries, which is one of the few things I've really found myself still fighting in Ada. I don't think it's a general solution to the whole thing, but I'll happily take it.
- MaxBarraclough 4y agoI had the same thought. Ada is famous for its strong typing, i.e. the absence of implicit type conversions of the sort that are such a nightmare in C.