On 28 July 2017 at 21:20, 12345swordy via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On Friday, 28 July 2017 at 18:24:02 UTC, H. S. Teoh wrote: >> >> On Fri, Jul 28, 2017 at 05:38:10PM +0000, Stefan Koch via Digitalmars-d >> wrote: >>> >>> [...] >> >> >> Not necessarily. Perhaps "IR" is the wrong term to use, as in compiler >> parlance it means something very close to machine code, but the idea is that >> the core language should provide enough semantics that you can still >> introspect and reason about it meaningfully. To use the C++ example, it >> would provide semantic notions like access permissions, so that you can >> still meaninfully introspect whether a method is public, private, protected, >> etc.. >> >> [...] > > > Reading through the dlang documentation, I can't find a way to enforce a > certain code standard using mixins _traits ctfe. > For example you have a custom allocator and you forbid using c malloc in > functions and class constructor, and you create the @noMalloc to achieve > this. To me that what's currently missing in D. To enforce certain code > standards in projects to prevent developers accidentally using a certain > function/class that is forbid by the custom attribute and that is not > covered by the current attributes(safe, nogc, etc). > > Imo it's very beneficial to have coding standards enforce by compile time.
Sounds an awful lot like how people use UDAs and compile-time introspection to me.