On Apr 30, 2013, at 12:45 , Sean Silva <[email protected]> wrote: > > On Tue, Apr 30, 2013 at 1:55 PM, David Blaikie <[email protected]> wrote: > * should we consider adding an ArrayRef implicit ctor from "None"? > (see llvm/ADT/None.h and its use in llvm/ADT/Optional.h) Then you > could replace all the "ArrayRef<T>()" calls with "None" (you might > even want to do a sed replace on existing instances of this as a > separate patch (a purely mechanical patch is easy to review/apply)). > > What's wrong with `ArrayRef<T>()`? It's explicit and clear. What is the > benefit of writing `None` instead? IMHO if I saw "None" that would just > confuse me and send me on a wild goose chase that would eventually terminate > on finding the implicit ArrayRef ctor and then saying to myself "why the heck > didn't they just write `ArrayRef<T>`"?
I like None. In argument lists with possibly empty arrays, specifying the empty array by type is weird and brittle. Normally, in an argument list you have values: invalidate(ConstArgs, NonConstArgs); and if one of those arrays is empty, you start mixing values and types when you're reading: invalidate(ArrayRef<SVal>(), NonConstArgs); Not to mention that if you decide to change the type of this thing, and it's threaded through multiple functions, you'd normally only have to change the function headers...but now you have to change some (but not all) of the call sites as well: invalidate(ArrayRef<const MemRegion *>(), NonConstArgs); even though that particular caller is still semantically doing the same thing: invalidate(None, NonConstArgs); It's really the same argument as "why not Optional<T>"? I personally find None much nicer than Optional<T>. Jordan
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
