> On Sep 19, 2017, at 12:31, Joe Groff via swift-dev <swift-dev@swift.org>
> wrote:
>
>
>
>> On Sep 19, 2017, at 5:19 AM, David Zarzycki via swift-dev
>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>>
>>
>>
>>> On Sep 18, 2017, at 17:54, Ben Cohen via swift-dev <swift-dev@swift.org
>>> <mailto:swift-dev@swift.org>> wrote:
>>>
>>>
>>>
>>>> On Sep 13, 2017, at 1:06 PM, David Zarzycki via swift-dev
>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>>>>
>>>>
>>>>
>>>>> On Sep 13, 2017, at 15:23, Matthew Johnson via swift-dev
>>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>> On Sep 13, 2017, at 11:56 AM, David Zarzycki via swift-dev
>>>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Sep 13, 2017, at 13:53, David Sweeris <daveswee...@mac.com
>>>>>>> <mailto:daveswee...@mac.com>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On Sep 13, 2017, at 09:54, David Zarzycki via swift-dev
>>>>>>>> <swift-dev@swift.org <mailto:swift-dev@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
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
