[cfe-dev] [ clang::Optional ] History Digging

[David Blaikie via cfe-dev]

On Mon, Aug 20, 2018 at 12:17 AM ThePhD <jm3689 at columbia.edu> wrote:

> Dear David,
>
>      Thanks for explaining all of that to me! I feel like I'm starting to
> come to a close from all the surveying of the optional implementations and
> usages thus far. I think there's only one question I have left, though, and
> it has to do with the use of T* as a "optional rebind-able reference".
>
>      Has the use of T* for this purpose ever had any problems? I would
> imagine that people used to the codebase have gotten used to it, but has it
> ever needed explaining or clarification in places about what the raw
> pointer's purpose was to a newcomer?
>
>      I ask mostly because I've seen T* used for a -lot- of different
> purposes, so I generally get curious if having it as an "optional
> rebind-able reference" has ever led to confusion for the other (mis?)uses
> attributed to the syntax.
>

I don't know of any concrete examples to cite, but I'm sure it causes some
confusion around "is this an owning pointer or an optional rebindable
reference or a place where a reference can't be used for some other reason"
but with the advent of smart pointers for ownership, raw pointers become
less of a concern I think.


>
> Sincerely,
> ThePhD
>
> On Tue, Jul 10, 2018 at 3:17 PM David Blaikie <dblaikie at gmail.com> wrote:
>
>> Hi there,
>>
>> Source control has most of the history - and in this particular case,
>> it's so far back in the earlier days of LLVM/Clang (Optional was originally
>> committed to Clang without any pre-commit review that I can see - in r78342
>> (git hash d4e5a606c9c64e24c05e5f4610796087e911fb9c)).
>>
>> It looks like the original version didn't have any particular support for
>> references, though it probably would've worked in that initial simple
>> version. Since then no one's attempted to add support for references and
>> additional complexity of other features (construction from rvalue
>> references, etc) without concern for references has broken any incidental
>> reference support it may've had.
>>
>> So I don't think it was some explicit choice not to support it - but a
>> lack of need & probably by the time folks (such as myself) were talking
>> about whether it should support references, there was enough open
>> discussion about the traedoffs/complexities of supporting them (thanks to
>> the committee discussions, etc) that there was probably at least a little
>> hesitance - likely enough to err on the side of "let's just keep doing
>> things the way we have and use raw pointers for 'optional rebindable
>> references'".
>>
>> On Mon, Jul 9, 2018 at 3:49 PM ThePhD via cfe-dev <cfe-dev at lists.llvm.org>
>> wrote:
>>
>>> Dear Clang Developers,
>>>
>>>      I am trying to do a little bit of history diving. Back in 2010
>>> clang::Optional was moved to llvm::Optional, and has since then maintained
>>> its current interface with minor fixes / changes here and there.
>>>
>>>      I was interested in finding out the initial motivation for
>>> clang::Optional, and what features it wanted to support. In particular,
>>> clang::Optional doesn't feature support for references, and a few other
>>> minor things that differ from the dominating optional implementation around
>>> the time of its transition and inception: boost::optional. This is one of
>>> the only optionals of its time that publicly made its own design decision,
>>> before "because the proposal / standard told me so" was a valid reason for
>>> doing so.
>>>
>>>      Does anyone know if clang::Optional's design was discussed at all?
>>> Or if there are any archives for said discussion? This is a bit of an
>>> archaeology question, but I was hoping I could get answers nonetheless!
>>>
>>
>>> Sincerely,
>>> ThePhD
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180820/48a99a7d/attachment.html>