<div dir="ltr">Hi Rafael,<div><br></div><div>> <span class="im" style="font-size:13px">> In the long-term I expect many parts of LLVM may want to migrate from<br>> > std::error_code to TypedError, but that's ultimately a decision for the<br>> > maintainers of the respective parts. I'll be very happy to provide input and<br>> > support, but I don't want to pre-empt anyone else's decision on whether to<br>> > adopt this.<br><br></span><span style="font-size:13px">> That means we will forever have an incomplete transition.</span><div><span style="font-size:13px"><br></span></div><div>I included that caveat because it's not my place to insist on adoption, but it is my hope is that this system could eventually replace other error-return systems in LLVM.</div><div><br></div><div>> <span style="font-size:13px">But *please*, make an effort to use it everywhere. We still have a mix</span></div><span style="font-size:13px">> of bool+std::string, std::error_code and ErrorOr. Are each of these</span><br style="font-size:13px"><span style="font-size:13px">> better than what you are proposing in one case or the other? Probably.</span><br style="font-size:13px"><span style="font-size:13px">> Is it worth it having unique snow flakes?  I don't think so.</span><br style="font-size:13px"><br>I'm happy to take this approach, and I agree: having a consistent scheme for error returns everywhere is ideal. <br><br style="font-size:13px"><span style="font-size:13px">> In particular, please don't change just the "MachO-specific part of</span><br style="font-size:13px"><span style="font-size:13px">> X". In the past I have made an effort to keep MachO bits current when</span><br style="font-size:13px"><span style="font-size:13px">> working in MC and lib/Object. Please do the corresponding effort. For</span><br style="font-size:13px"><span style="font-size:13px">> </span><span style="font-size:13px">example, if you change llvm-nm, please change all of it</span><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">I'm also happy to do this.</span></div><div><span style="font-size:13px"><br></span></div><div>It's neither practical nor prudent to try to re-write the world in one go, so there's no escaping a transition period with some glue code. That's no reason not to do this though, and assuming the community's experience with the system is as positive as mine was with the prototype, I think we could aim to move to this as an essentially universal error-return solution in the future.</div><div><br></div><div>Cheers,</div><div>Lang.</div><div><span style="font-size:13px"><br></span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 10, 2016 at 7:19 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> In the long-term I expect many parts of LLVM may want to migrate from<br>
> std::error_code to TypedError, but that's ultimately a decision for the<br>
> maintainers of the respective parts. I'll be very happy to provide input and<br>
> support, but I don't want to pre-empt anyone else's decision on whether to<br>
> adopt this.<br>
<br>
</span>That means we will forever have an incomplete transition.<br>
<br>
We still haven't finished moving to the "new" naming style. Moving to<br>
the current path handling took from Nov 2009 to Jun 2013.<br>
<br>
I am still not convinced that the new system is better than a<br>
asserting wrapper over std::error_code with diag handlers, but I don't<br>
have the time to change Orc to use to show it. Given that I also<br>
failed to convince you otherwise, we will probably have to go with the<br>
view of who can actually code this.<br>
<br>
But *please*, make an effort to use it everywhere. We still have a mix<br>
of bool+std::string, std::error_code and ErrorOr. Are each of these<br>
better than what you are proposing in one case or the other? Probably.<br>
Is it worth it having unique snow flakes?  I don't think so.<br>
<br>
In particular, please don't change just the "MachO-specific part of<br>
X". In the past I have made an effort to keep MachO bits current when<br>
working in MC and lib/Object. Please do the corresponding effort. For<br>
example, if you change llvm-nm, please change all of it<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>