Nathan Froyd writes:
> I think a broader definition of "POD struct" would be required here:
> RefPtr<T> and similar are technically not POD, but I *think* you'd
> want to require RefPtr<T>* arguments when you expect the smart pointer
> to be assigned into? Not sure.
Yes, please, for similar reasons as for the primitive types.
>On Tue, May 9, 2017 at 10:39 AM, Boris Zbarsky <bzbar...@mit.edu> wrote:
>> But for object-typed things like dom::Element or nsIFrame, it seems better
>> to me to pass references instead of pointers (i.e "Element&" vs "Element*")
>> for what are fundamentally in params, even though the callee may call
>> mutators on the passed-in object. That is, the internal state of the
>> element may change, but its identity will not.
Nathan Froyd writes:
> I get this argument: you want the non-nullability of references, but
> you don't want the verboseness (or whatever) of NonNull<T> or similar,
> so you're using T& as a better T*. I think I would feel a little
> better about this rule if we permitted it only for types that deleted
> assignment operators. Not sure if that's really practical to enforce.
With convention to use references to objects for methods that
change the state of the object, the advantages are
R1. Nullability is indicated differently from NotNull<T>.
R2. Parameters which may change the identity of an object can be
distinguished at the call site from those that may change only
state.
With convention to use pointers to objects for methods that change
the state of the object, the advantages are
P1. Parameters which change the state of an object can be
distinguished at the call site from those that don't.
P2. Consistency with primitive types.
My experience is that for understanding while reading code, it is
more helpful to distinguish where state may be modified than to
distinguish what may be null. One particular case is where a
method transfers state from one object to another. At the call
site it is useful to distinguish source from destination.
For object types, change in identity is rare (non-existent for
ref-counted objects) and so there is rarely a need to distinguish
this from state change. Typically identity changes only when the
pointer changes.
Doesn't NotNull<T> provide that pointers can have the same
advantages as references re visibility of nullability where
desired, so we can have the best of both?
Or is NotNull really too awkward IRL?
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
