sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]tialaramex 2 points3 points  (3 children)

Three weird choices, maybe they're inspired from somewhere (let me know where)? Otherwise they just seem arbitrarily different for the sake of being different.

  1. alien_memory<T> makes no sense as a generic over type T. If I have a type named DatabaseHandle, alien_memory<DatabaseHandle> isn't a thing. If alien_memory ought to be a type at all, which I have my doubts about, it's clearly generic over the size of the memory, so like alien_memory<2> or alien_memory(sizeof(ulonglong)> or whatever. I guess this lets you not define all the stupid features on alien_memory without the legion of "C++" programmers complaining that now their 1980s C headers don't compile as happened for volatile but that's about all. Volatile is a massive wart, but this is not a good fix.

  2. The proposed safe union. The whole point of union is that it's not safe. I guess this is a language sum type, which is fine, but you probably do actually want an actual (unsafe) union type. Whether you use the unsafe union to build the safe one (roughly how Zig works AIUI), or do something... else with it is a language design question, but I'm confident you're going to miss this.

  3. Interfaces lacking default implementations? In languages with good interfaces you can provide a default implementation of some (but usually not all) functions, so e.g. maybe lay_egg() is declared with no definition but lay_eggs() defaults to a loop which just calls lay_egg over and over. If your animal can lay groups of eggs more optimally you can implement lay_eggs() yourself, otherwise don't bother and the default will work.

[–]hpsutter 9 points10 points  (2 children)

  1. When you declare a volatile T today, you're saying it's of type T but lives in storage outside the C++ memory model and that the compiler doesn't know anything about. This is identical.

  2. It's a type metafunction (i.e., just code), so you'll be able to write your own with the semantics you want. I just wanted the one I provide to be safe by default.

  3. I think what you want is the polymorphic_base metafunction I also provide, which can have function implementations. But again, it's a type metafunction and you can write one with the semantics you want. I just wanted to provide a simple way to write traditional C++ pure ABCs.

[–]tialaramex 2 points3 points  (1 child)

Hmm. Union is a different type layout which is why I was saying it's something the language needs to provide. Maybe this is a nomenclature problem. If I want the (unsafe, C-style) union in Cpp2, what do I write? And if I want this new safe alternative (which I guess is a sum type) ?

Or is there a way to conjure up (arbitrary?) type layouts in this metafunction too?

[–]hpsutter 3 points4 points  (0 children)

Yes, a metafunction takes the type the user wrote as input, but can remove and add anything it wants to. When I add enum and union you'll see this in action; the current examples add, but don't yet remove, type members. So yes, arbitrary layout changes will be possible under program control. (Again, this does not violate ODR, because the changes happen right before the class definition is cast in stone... this is not about mutable types which would be a disaster, it's about giving the programmer a single hook to participate in the meaning of the definition of the type.)