<p dir="ltr">Hey Brent, </p>
<p dir="ltr">I really like the idea you proposed with having a Reference nested type. I prefer a name like Object but that's just me.</p>
<p dir="ltr">From my experience, nested types don't conflict with typealiases for protocol conformance so you could do something similar to:</p>
<p dir="ltr">extension Array: Referable {<br>
class Reference<Element> { ... }<br>
var reference: Reference<Element> { ... }<br>
}</p>
<p dir="ltr">I do agree with Tony however that types like NSBundle that have no Swift counterpart could be renamed to simply Bundle.</p>
<p dir="ltr">One thing I'm wondering about is abuse of the Referable protocol. It could lead to developers feeling the need to conform to it when it comes to creating new value types. However, it shouldn't be an issue. </p>
<br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 4, 2015, 3:09 PM Brent Royal-Gordon <<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> We’ve been thinking about exactly what to call this submodule, but haven’t landed on a preferred name yet. For the class names themselves, I don’t think we want to suffix some classes with ‘Ref’ or ‘Object’ but not others, because it would lead to either boilerplate names or inconsistency. The idea of the submodule was to avoid the inconsistency but still have something which obviously separates these classes.<br>
<br>
But I’m not sure using a submodule really solves either of these problems.<br>
<br>
BOILERPLATE: How are you going to address types inside the module? Either you’ll have to always include the prefix—in which case the prefix is boilerplate, but it’s in the wrong place on the type name to read correctly (“reference array” instead of “array reference”) and requires an extra character due to the “.”—or there will be some way to make Swift favor the reference types over the value types, in which case you won’t even be able to read “Array” or “String” in a piece of code without wondering which semantics you’re talking about.<br>
<br>
INCONSISTENCY: Not every type in Foundation will be moved into this submodule; some will stay behind in the top-level Foundation module. Doesn’t that mean the submodule approach is inconsistent too?<br>
<br>
So is putting these types into a submodule actually fixing these problems, or is it just sticking a dot after them?<br>
<br>
Actually, as long as we’re here, here’s a weird idea I just came up with. Why not nest the reference types inside the types they bridge to?<br>
<br>
NSString -> String.Reference<br>
NSMutableString -> String.MutableReference<br>
NSArray<T> -> Array<T>.Reference<br>
NSMutableArray<T> -> Array<T>.MutableReference<br>
<br>
This would require you to get a handle on nesting types within generic types, but personally, that’s always been a pain point for me in Swift’s design. With the right type resolution rules, it might also allow you to say something like this and let Swift figure out what you mean:<br>
<br>
let foo = “foo bar baz” as .Reference // implicitly means String.Reference<br>
<br>
And if this was driven by a protocol with a typealias for the reference type, you could even make this public so users who have their own matching value/reference types can have them autoboxed:<br>
<br>
// Think of this as a cleaned up version of _ObjectiveCBridgeable.<br>
public protocol Referable {<br>
typealias Reference: class<br>
static func referenceType() -> Reference.Type // or make it possible to get this from the protocol witness<br>
<br>
var reference: Reference { get }<br>
init?(reference: Reference) // for an as! conversion, this is force-unwrapped by the caller<br>
}<br>
<br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>