[llvm-dev] RFC: Strong typedef for LLVM

[Reid Kleckner via llvm-dev]

On Thu, Aug 1, 2019 at 9:41 AM Doerfert, Johannes via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> +1, I like this a lot.
>
> Recently, I started to use two element `enum class`es to force people
> (mostly me)
> to spell out what true/false actually means in a certain context. The
> solution proposed
> here comes with more boilerplate but once available it is nicer (I think)
> and for sure
> more generic.
>

I agree, I think for bools, an enum class is the simplest language provided
way to get most of the benefits that a strong typedef (or value wrapper
class) would provide. I would prefer to keep using them for these cases,
especially for widely used user facing APIs. The less publicly visible the
function is (private method, file local static, etc), the more inclined I
am to just keep doing what we're doing for expediency and brevity.

For integer values that are easy to confuse (physical register numbers,
byte quantities, bit quantities, alignments, etc), I agree, we should be
leveraging the type system more than we are. Adding a strong typedef class
to make it easier to make these types with less boilerplate would be great.
See existing prior art for this kind of stuff in clang::CharUnits.

I suppose I don't love the name "strong typedef", since it kind of implies
a value judgement that C typedefs are weak, and therefore worse. They
aren't worse, they just aren't well suited to this use case and have other
strengths and weaknesses. I see that the C++ paper
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0109r0.pdf>
proposes calling these "opaque typedefs". I don't know if that's the best
name, but I prefer that shade of paint. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190801/19007d7f/attachment.html>