233384 2021-11-19 14:36:11 -0800 Ref<T> should support indirection operator * 2022-02-17 01:50:06 -0800 1 1 1 Unclassified WebKit Web Template Framework Other Unspecified Unspecified RESOLVED WONTFIX InRadar P2 Normal --- 1 jean-yves.avenard webkit-unassigned achristensen cdumez darin ggaren koivisto mark.lam rniwa webkit-bug-importer ysuzuki zalan oldest_to_newest 1817002 0 jean-yves.avenard 2021-11-19 14:36:11 -0800 While Ref<T> was supposed to be a replacement for T& with lifetime guarantees, C++ limitations made it act more like a pointer than a reference. Ref<T> is more like a RefPtr<T> that guarantees it's never null. A Ref can be converted into a RefPtr directly. You already have to dereference the content of a Ref<T> using operator->(). So it makes sense that it also implements the indirection operator *. I propose that Ref<T> be made to at the very least support the indirection operator and maybe even be officially be made into just a RefPtr that guarantees to never be null (so get() would return T* rather than T& 1817029 1 achristensen 2021-11-19 15:36:58 -0800 To me, the indirection operator is used when you have something that might be null/nullopt/error, so you check if (thing) { useThing(*thing); } but that isn't the case with Ref. It never needs checking whether it's null because if you haven't used it after you moved from it, it's never null. Adding the indirection operator would make it so when we write code that just calls useThing(*thing), we now have to think about whether it is a Ref or not. Also, when someone down the line changes thing from a Ref to a RefPtr, we would then have code that may not be nearby that needs a null check, but you didn't notice it because it compiled fine. This really needs operator dot, but C++ doesn't allow that. It currently follows the convention of unique_ptr<T>::get which returns a T*, but it returns a T&. Maybe we could implement Ref<T>::operator& instead of Ref<T>::ptr to get a T*, though. That would be nicer syntactically. 1817030 2 ggaren 2021-11-19 15:46:06 -0800 Jean-Yves mentioned on Slack that supporting operator*() would make converting from RefPtr<T> to Ref<T> easier. Alex seems to be pointing out that supporting operator*() would make converting from Ref<T> to RefPtr<T> harder / more error-prone. It seems like the logic here is the same: There's an impedance mismatch because Ref<T> offers more than RefPtr<T>. 1817070 3 rniwa 2021-11-19 20:42:25 -0800 I'm pretty this is an intentional design choice because we wanted it to act like a reference. This is why Ref has operator T& whereas RefPtr doesn't, and Ref::get returns T& instead of T* as in RefPtr::get. To get a pointer, you call Ref::ptr instead. I actually don't understand why we want operator *. Why would operator T& not be sufficient? 1817075 4 jean-yves.avenard 2021-11-19 21:53:13 -0800 (In reply to Ryosuke Niwa from comment #3) > I'm pretty this is an intentional design choice because we wanted it to act > like a reference. Indeed that was the intent, but the lack of operator.() in C++ makes it that you have to use -> to dereference it; as such, in practice it works like a pointer. > I actually don't understand why we want operator *. Why would operator T& > not be sufficient? Yes, Alex made a good point there. As Geoffrey mentioned, currently there's a mismatch between intent and actual usage. 1817085 5 koivisto 2021-11-19 23:16:08 -0800 Originally Ref had just get() (since operator.() doesn't exist in C++). It was considered too verbose so operator->() was added as a somewhat inconsistent workaround. This doesn't mean it should have pointer-like semantics in general. 1817092 6 rniwa 2021-11-20 00:04:52 -0800 (In reply to Jean-Yves Avenard [:jya] from comment #4) > (In reply to Ryosuke Niwa from comment #3) > > I'm pretty this is an intentional design choice because we wanted it to act > > like a reference. > > Indeed that was the intent, but the lack of operator.() in C++ makes it that > you have to use -> to dereference it; as such, in practice it works like a > pointer. Just because the presence of operator-> doesn't make it a pointer like. Ref::operator! works like T::operator! so it's not pointer-like in that regard for example. In fact, almost everything else doesn't behave like a pointer. 1817093 7 rniwa 2021-11-20 00:05:07 -0800 FWIW, I'm opposed to the proposed change. 1818002 8 webkit-bug-importer 2021-11-26 14:37:25 -0800 <rdar://problem/85773648>