<div dir="ltr"><div dir="ltr">Hi Herb,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 12, 2019 at 7:34 PM Herb Sutter <<a href="mailto:herb.sutter@gmail.com">herb.sutter@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-8623136628101329238WordSection1"><p class="MsoNormal">Gábor wrote:<u></u><u></u></p><p class="MsoNormal">> I would love to see a simpler syntax. I think implementing this the most general<u></u><u></u></p><p class="MsoNormal">> way possible and adding some syntactic sugar later on after having some data<u></u><u></u></p><p class="MsoNormal">> about the most common patterns might make sense.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Yes. In particular, the nicest “nice syntax” of all is intended by design to be <b>whitespace</b> for the large majority of functions, via defaults that are equivalent to default annotations… the <a href="https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/Lifetime.pdf" target="_blank">Lifetime design paper</a> proposes such defaults (in sections 2.5.3 and 2.5.5), and the aim is that very few functions ever want explicit annotation.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">So far in our experience that has been working very well, including that the large majority of std:: standard library functions just work unchanged without annotation:<u></u><u></u></p><ul style="margin-top:0in" type="disc"><li class="gmail-m_-8623136628101329238MsoListParagraph" style="margin-left:0in">To see basic examples, please look at <a href="https://godbolt.org/z/1C4t8m" target="_blank">https://godbolt.org/z/1C4t8m</a> (which involves std::min) and <a href="https://godbolt.org/z/4G-8H-" target="_blank">https://godbolt.org/z/4G-8H-</a> (which diagnoses a StackOverflow question involving unique_ptr). No annotation of the standard library was needed in either example, they use the stock unmodified std:: implementation.*<u></u><u></u></li><li class="gmail-m_-8623136628101329238MsoListParagraph" style="margin-left:0in">For an (IMO pretty slick) example of zero-annotation of more complex code, see <a href="https://godbolt.org/z/eqCRLx" target="_blank">https://godbolt.org/z/eqCRLx</a> – the code it diagnoses is actually quite complex (vector push_back but also ranges with filtering views) and all unannotated, and it gives nice and accurate diagnostics (pretty much “hey, your ranges::view::filter is dangling here on line B, because your vector<int>.push_back() invalidated it here on line A”).<u></u><u></u></li><li class="gmail-m_-8623136628101329238MsoListParagraph" style="margin-left:0in">See also section 2.6.2 in the design paper which shows that the string_view dangling problem examples given in WG21 paper P0936 are (I think all) diagnosed without any explicit annotation, because the proposed defaults do the right thing.<u></u><u></u></li></ul><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Those are examples, many of them drawn from real-world code, that needed no annotation at all with the proposed default annotations.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">So I would propose this:<u></u><u></u></p><ol style="margin-top:0in" start="1" type="1"><li class="gmail-m_-8623136628101329238MsoListParagraph" style="margin-left:0in">Implement the general form. We know that occasionally we’ll need that, and then we can express anything in #2 and #3 as equivalents/sugars for something expressible in #1.<u></u><u></u></li><li class="gmail-m_-8623136628101329238MsoListParagraph" style="margin-left:0in">Implement the proposed default rules (including tweak them as we gain experience in larger codebases) so that whitespace zero-annotation Just Works for (we hope) a very large number of functions.<u></u><u></u></li><li class="gmail-m_-8623136628101329238MsoListParagraph" style="margin-left:0in">Then see if we actually need any in-between syntactic sugars at all. If #2 covers a sufficiently high % of functions, we may not even be interested in other sugars. And if we discover there are patterns that #2 doesn’t cover well, then we can add sugars for those patterns.<u></u><u></u></li></ol><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">How does that sound?</p></div></div></blockquote><div><br></div><div>I have studied your paper in detail quite some time ago, so I'm familiar with the proposed inference rules -- but thanks for reminding me. I'm still skeptical that the explicit annotations would be rare enough that readability of the general syntax is irrelevant. Anyway, the only way to find out is to try to annotate real-world code, and for that we need tooling support first (e.g., this warning) to find where we need annotations. While it is good that the standard library required few annotations, I don't think the standard library is representative of real-world business logic that engineers write today, or of legacy data structures and APIs that companies have accumulated over the decades.</div><div><br></div><div>In other words, I agree with your plan, but I think the chances are very low that we won't need to do anything in #3.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-8623136628101329238WordSection1"><p class="MsoNormal">* As a temporary implementation detail, the prototype does currently hardwire knowledge that unique_ptr and vector are owners, but there also proposed default zero-annotation rules for automatically recognizing which types are Owners (see section 2.1) which recognize those types without annotation (e.g., it recognizes containers and smart pointers as implicitly Owners).<br></p></div></div></blockquote><div><br></div><div>I actually think that annotating owner types is a good idea. The cost of an inference failure for an owner type is too high, and debugging it would be non-trivial even for experts (what did *exactly* prevent this type from being inferred to be an owner?) Annotating owners is also good as a matter of documentation. I am not worried about annotation cost for owner types, since they are going to be quite rare.</div><div><br></div><div>Dmitri</div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature">main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br>(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" target="_blank">gribozavr@gmail.com</a>>*/</div></div>