<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Aug 24, 2017, at 10:41 AM, David Zarzycki <<a href="mailto:zarzycki@icloud.com" class="">zarzycki@icloud.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 24, 2017, at 00:08, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class=""></div></blockquote><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class="">What do people think? The meat of the change is tiny and below. The vast majority of the work is the long and painful fallout in the test suite, which I’m cautiously (and perhaps foolishly) stepping up to doing.</div></div></div></div></div></div></div></div></blockquote><div class=""><br class=""></div>I think that’s an interesting improvement in this specific message, but it's not obvious that it would be an improvement to all messages.</div></div></blockquote><div class=""><br class=""></div>Hi John,</div><div class=""><br class=""></div><div class="">That is certainly true. I’ve already seen that after a few rounds of testing this and watching the changing output from the test suite. That’s why I emailed this list before getting too deep into this change. In general, I thought the output was better than before, but reasonable people might disagree. The only place where I felt the extra verbosity was clearly distracting was/is the ‘where’ clause diagnostics.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Generally the way we did things like this in Clang was to add a modifier to the diagnostic string, so that it would look something like "%type1", which would be understood to expand to a noun appropriate for the type. That way, it was easy to take advantage of it for a specific diagnostic, but you weren't forced into it by default. I think that’s still the right approach here.</div></div></blockquote></div><div class=""><br class=""></div><div class="">Interesting. Good to know. Setting aside what the default should be, and unless I’m missing something, the clang style “%type1” approach has the same underlying challenges as this patch:</div><div class=""><ol class=""><li class="">The verbosity snowballs because the goal of printing the inner decl kind is complicated by having layered type qualifiers (optional, metatype, etc).</li><li class="">Having two very different approaches to printing a type during diagnostics is lame (i.e. dense native syntax versus verbose English descriptions).</li></ol></div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Maybe the “right” approach – and I’m only half serious about this – is to have a way for the compiler to print <span style="font-family: Courier;" class="">‘(/*struct*/Foo).Type?’</span>. Is it ugly? Arguably. Is it dense? Yes. Does it snowball? No. Does it scale? Absolutely! For example, consider a nontrivial “optional dictionary of tuple” type. It might look like this: <font face="Courier" class="">‘[/*struct*/String : (/*class*/Foo, /*enum*/Bar)]?’</font>. If knowing the decl kind is helpful, then the latter output is a huge improvement.</div><div class=""><br class=""></div><div class="">For whatever it may be worth, I’m not wed to this proposal. The motivation behind this patch was preparation for the eventual day when a new nominal type is created (like Chris’s “actor” proposal or something else). I could certainly narrow the scope of this work to rewording some of the diagnostics to be more decl kind agnostic. For example: “subclass” becomes “subtype”, “superclass type” becomes “inherited type”, etc. If people are open to that, I can narrow the focus of this work.</div></div></div></div></blockquote><div><br class=""></div>I think making it easy to have a better noun than "type" before a type in a diagnostic is valuable, but yeah, I think you need to:</div><div> - take it as a mission to not use more than two words as an introducer</div><div> - be cool with falling back to "type" if you're not sure what else to say</div><div> - think carefully about whether using a more specific noun than "type" is really providing any non-obvious information</div><div><br class=""></div><div>For example, "type" is probably fine to introduce function types, because it's usually visually obvious that a type is a function type. On the other hand, you could consider using a more precise noun in the same sort of situations where you might print an aka clause, e.g.:</div><div> can't frobonicate with function type 'HappyCallback' (aka '(HappyContext) -> ()')</div><div><br class=""></div><div>Finally, of course, it's okay just to make incremental improvements instead of trying to make everything perfect all at once. :)</div><div><br class=""></div><div>John.</div></body></html>