<div dir="ltr"><div dir="ltr">On Thu, Aug 1, 2019 at 9:41 AM Doerfert, Johannes via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">+1, I like this a lot.<br>
<br>
Recently, I started to use two element `enum class`es to force people (mostly me)<br>
to spell out what true/false actually means in a certain context. The solution proposed<br>
here comes with more boilerplate but once available it is nicer (I think) and for sure<br>
more generic.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0109r0.pdf">C++ paper</a> proposes calling these "opaque typedefs". I don't know if that's the best name, but I prefer that shade of paint. :)</div></div></div>