> On Sep 19, 2017, at 12:51, Joe Groff <jgr...@apple.com> wrote: > > > >> On Sep 19, 2017, at 9:48 AM, David Zarzycki <d...@znu.io >> <mailto:d...@znu.io>> wrote: >> >> >> >>> On Sep 19, 2017, at 12:31, Joe Groff via swift-dev <swift-dev@swift.org >>> <mailto: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? > > > My concern is that "not class" by itself doesn't really enforce anything > interesting over no constraint at all. As Ben noted, it may also be harmfully > misleading to people who think it means more than it does.
Thanks for clarifying. Sounds like I should keep this patch on my side branch where I’m exploring enforced value semantics (as a prerequisite to larger goals). Thanks, Dave
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
