[swift-dev] Value-type bound protocols?

[David Zarzycki]

> On Sep 19, 2017, at 12:31, Joe Groff via swift-dev <swift-dev at swift.org> wrote:
> 
> 
> 
>> On Sep 19, 2017, at 5:19 AM, David Zarzycki via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> 
>> 
>> 
>>> On Sep 18, 2017, at 17:54, Ben Cohen via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>> 
>>> 
>>> 
>>>> On Sep 13, 2017, at 1:06 PM, David Zarzycki via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Sep 13, 2017, at 15:23, Matthew Johnson via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>>> On Sep 13, 2017, at 11:56 AM, David Zarzycki via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Sep 13, 2017, at 13:53, David Sweeris <davesweeris at mac.com <mailto:davesweeris at mac.com>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>> On Sep 13, 2017, at 09:54, David Zarzycki via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>>>>>>> 
>>>>>>>> Hello,
>>>>>>>> 
>>>>>>>> As a part of a research project that I’m working on, I’ve started bumping into the need for value-type bound protocols (as opposed to the existing class bound protocols). Is this something that would be worth proposing formally? Or should I just keep the patch I have on my research branch?
>>>>>>> 
>>>>>>> I think it'd be worth a proposal, especially if can talk about why you needed it.
>>>>>> 
>>>>>> While I look forward to talking about my research, I’m not ready to do in the near future.
>>>>>> 
>>>>>> That being said, value-type bound protocols seem independently useful and that is why I emailed the list.
>>>>>> 
>>>>>> I think the use case for this is generic algorithms. Why? Because it can be hard to impossible to write *robust* generic code when you don’t know whether an abstract type copies by value or by reference during assignment/initialization. With class-bound protocols, you can guarantee reference semantics, but there is no analogous feature for ensuring value semantics. I have a small (~150 line) patch that fixes this.
>>>>> 
>>>>> Value types and value semantics are not the same.  Most people who have asked for this capability actually want a constraint for value semantics, not value types.  Is that what you're asking for as well?
>>>> 
>>>> The patch that I’m ready to put forth is only a value-type bound. In other words only structs and enums would be able to conform to a value-type bound protocol. Enforcing value semantics is arguably a separable language goal.
>>>> 
>>> 
>>> But knowing something is a value type isn’t particularly useful, given it doesn’t guarantee value semantics. It could even do more harm than good, by being confusable with enforcing value semantics. 
>>> 
>>> Can you go into the use cases you have where you would use the knowledge that a type is a value type?
>> 
>> 
>> Hi Ben,
>> 
>> As a part of a much larger goal, I’m experimenting with enforced value *semantics* and I found that value-type bound protocols are a wholly separable and independently useful prerequisite. Here is a contrived but representative example:
>> 
>> protocol ValueThingy : !class { // From the patch sent to the list
>>   mutating func increment()
>> }
>> 
>> func incrementByCopy<T : ValueThingy>(_ arg : T) -> T {
>>   var copy = arg
>>   copy.increment()
>>   return copy
>> }
>> 
>> Without value-type bound protocols, generic code cannot ensure that required copies are actually happening. This is independently useful and good.
> 
> As others have noted, this doesn't by itself guarantee anything.

…

> 
> The more fundamental thing I think we're looking for in this space is a "pure" restriction for functions and methods, meaning they only access non-shared-mutable data. Any annotation at the type level is not going to give strong enough guarantees to build sound abstractions on top of.

Hi Joe,

I know that this doesn’t enforce value semantics. I thought I was being fairly clear about that. As I wrote, I see this change as a separable prerequisite to enforced value semantics. Are you suggesting that the core team views enforced value semantics as “all or nothing”? I.e. no incremental enforcement?

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170919/d25fee50/attachment.html>