[swift-evolution] Pre proposal: Should there be a way to distinguish class instances from struct instances

[Dave Abrahams]

Sent from my moss-covered three-handled family gradunza

> On Dec 17, 2015, at 4:26 PM, James Dempsey via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Daniel,
> 
> It occurs to me that if there was such a thing in Swift, the distinction would be lost in any code that used protocols for typing since both value and reference types can implement the same protocol.

In an ideal world, most protocols-at least those with mutating members- would be constrained to either value or reference-semantic types, as most generic components you can write inevitably make assumptions about the logical (in)dependence of a and b after you execute a = b. I'm sure the world would break if you made a CollectionType whose Index was a class, for example. But we don't currently have a way in the language to represent "has value semantics" (since value types can hold references) or "is constrained to have value semantics". 

> That doesn’t mean what you suggest would not be useful, just adding for consideration that there is a significant use case that potentially would not be covered.
> 
> James
> 
>> On Dec 17, 2015, at 4:23 AM, Daniel Steinberg via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> The way in which we reason about instances of value types and instances of reference types is significantly different and yet there is no way to easily distinguish them in Swift.
>> 
>> In Objective-C, for example, if we have an NSDate and an NSTimeInterval we can tell that NSDate is a reference type and NSTimeInterval is a value type by looking at how it is used in code
>> 
>> NSDate *myDate = //…
>> NSTimeInterval someTimeInterval = //…
>> 
>> The “*” helps us see that myDate is a pointer to an instance of NSDate.
>> 
>> We see this in methods that return values as well
>> 
>> - (NSString *)aStrringReturningMethod // …
>> - (NSInteger)numberOfMistakesInThisEmail //...
>> 
>> I realize that this is a result of Objective-C living in C’s world and we don’t have that constraint in Swift.
>> 
>> However, this means that when the semantics of variables, parameters, properties, and return values from methods is not always clear in our code. Because structs can have methods in Swift it is all to easy to confuse an instance of a struct with an instance of a class.
>> 
>> I may be alone here, but I think it would be less confusing if there were some way to distinguish between value types and reference types in code.
>> 
>> Thank you,
>> 
>> Daniel
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution