News for hackers. Stuff that matters.
Re:Metaclasses: Thoughts on generative C++ by lultimouomo on Friday July 28, 2017 @01:31AM (#14872192)
A snippet from the paper that made me understand what this is about:

  // $ is the reflection operator and T is a type.
  constexpr { // execute this at compile time
   for... (auto m : $T.variables()) // examine each member variable m in T
     if (m.name() == “xyzzy”) // if there is one with name “xyzzy”
       -> { int plugh; } // then inject also an int named “plugh”
  }
This would inject "int plugh;" in the scope surrounding the constexpr block.
Re:Metaclasses: Thoughts on generative C++ by JoshTriplett on Friday July 28, 2017 @02:14AM (#14872351)
This kind of compile-time code is a great substitute for things people currently do with template metaprogramming or code generators.
Re:Metaclasses: Thoughts on generative C++ by ta834939874 on Friday July 28, 2017 @02:14AM (#14872349)
reminds me of http://terralang.org/
Re:Metaclasses: Thoughts on generative C++ by tomovo on Friday July 28, 2017 @02:57AM (#14872493)
Re:Metaclasses: Thoughts on generative C++ by _pmf_ on Friday July 28, 2017 @03:18AM (#14872562)
I have hopes that Jai will be at a very nice local optimum regarding performance and productivity, but I think just like in C++, safety is not a major design goal (you need to be unsafe if working with memory mapped structs).
Re:Metaclasses: Thoughts on generative C++ by Rusky on Friday July 28, 2017 @10:49AM (#14874634)
> you need to be unsafe if working with memory mapped structs

Perhaps when defining their address and layout, or if they are a hardware structure that affects memory like a page table or TLB or a DMA controller, but beyond that, why? Or is that just the main use case you're describing?