Given that these are fairly low-level values with very specialized uses, I definitely agree that they should be somehow namespaced in a way that doesn't cause us to make very common words unusable for our users.
Even size(of:) seems more general to me than I'd like. I'd like to see the word "memory" as part of the name somehow, whether it's a wrapping type or a function prefix of some sort. These values are specialized; we don't need to optimize typing them, IMO. On Thu, Jun 2, 2016 at 2:06 PM Xiaodi Wu via swift-evolution < [email protected]> wrote: > On Thu, Jun 2, 2016 at 3:46 PM, John McCall via swift-evolution < > [email protected]> wrote: > >> On Jun 2, 2016, at 1:43 PM, Russ Bishop <[email protected]> wrote: >> >> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution < >> [email protected]> wrote: >> >> I still think the value-based APIs are misleading and that it would be >> better to ask people to just use a type explicitly. >> >> John. >> >> >> >> I agree; in fact *why aren’t these properties on the type itself*? The >> type is what matters; why can’t the type just tell me it’s size? >> Having free functions or magic operators seems to be another holdover >> from C. >> >> >> Int.size >> Int.alignment >> Int.spacing >> >> let x: Any = 5 >> type(of: x).size >> >> >> The compiler should be able to statically know the first three values and >> inline them. The second is discovering the size dynamically. >> >> >> Two reasons. The first is that this is a user-extensible namespace via >> static members, so it's somewhat unfortunate to pollute it with names from >> the library. The second is that there's currently no language mechanism >> for adding a static member to every type, so this would have to be >> built-in. But I agree that in the abstract a static property would be >> preferable. >> > > In the earlier conversation, it was pointed out (by Dave A., I think?) > that examples such as Array.size show how this solution can get confusing. > And even though there aren't fixed-length arrays in Swift, those may come > one day, making the syntax even more confusing. > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
