[llvm] r303011 - [StringExtras] Add llvm::to_integer.

[David Blaikie via llvm-commits]

On Fri, Jun 16, 2017 at 4:05 PM Zachary Turner via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On Fri, Jun 16, 2017 at 3:41 PM Justin Bogner <mail at justinbogner.com>
> wrote:
>
>> I'm a little late to the discussion, but I pretty strongly agree with
>> Rui's suggestion that returning an Optional is a better interface here.
>> I'm not really convinced that the cases where we can actually deduce a
>> type come up often enough that there's a significant useability
>> improvement.
>>
>
> I'm still not real crazy about it.  I don't like having to indent to
> handle the *success* case,
>

Don't have to, but yeah - does add some extra variables or indirection
syntax if it's done the other way. Eventually this'll get better with
coroutines.


> which you would see a lot of with an Optional<T> return and which goes
> against our coding standard guidelines of early return.  There's also the
> issue of size.  For example, an Optional<uint64_t> is 16 bytes, so it has
> non-zero performance cost
>

As do out parameters, of course - breaking aliasing assumptions/etc by
leaking the address of a local out into the rest of the program.


> and questionable style benefits.
>

I think the readability/self-documenting code of having single returns &
avoiding out parameters where it fits, is pretty high up there.

That's my take on it, at least.

- Dave


> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170616/b7be6ef7/attachment.html>