Re: [swift-evolution] [Proposal] Associated Type and Generic One-to-One Mapping

Yes, examples will be helpful. On Fri, Jun 23, 2017 at 19:28 David Moore via swift-evolution < swift-evolution@swift.org> wrote: > I do indeed have quite a few real examples of this, such prompted me to > bring this up. I think this could be done without any impact to existing > code, but it

Re: [swift-evolution] [Proposal] Associated Type and Generic One-to-One Mapping

I do indeed have quite a few real examples of this, such prompted me to bring this up. I think this could be done without any impact to existing code, but it would require some type of keyword. Take the following as a possible prototype. protocol Foo { associatedtype T } struct Bar : Foo

Re: [swift-evolution] [Pitch] `let` in protocols

What you want is some way to guarantee value semantics when writing generic code. It’s a known hole, and admittedly quite a big one. I hope that there will be time for core language improvements like this in Swift 5. Be sure to raise the issue again once planning for that starts! - Karl > On

Re: [swift-evolution] ability to derive a class from a struct or other value type

On Fri, Jun 23, 2017 at 17:59 Mike Kluev via swift-evolution < swift-evolution@swift.org> wrote: > On 23 June 2017 at 23:18, Tony Allevato wrote: > >> class C1: C2 ==> C1() is C2 == true >> class C1: P ==> C1() is P == true >> class C1: S ==> C1() is S == false? >>

Re: [swift-evolution] [Pitch] `let` in protocols

On Fri, Jun 23, 2017 at 16:43 Robert Bennett via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift Evolution, > > I’m bumping into an annoying problem with protocols. In a class or struct > it is common to have a `let` instance variable and assign it in `init`. > Unfortunately

Re: [swift-evolution] ability to derive a class from a struct or other value type

On 23 June 2017 at 23:18, Tony Allevato wrote: class C1: C2 ==> C1() is C2 == true > class C1: P ==> C1() is P == true > class C1: S ==> C1() is S == false? > ok. changing the rule then: C() is S == true foo(x) acts the same way as foo(x.super) bar() acts the

Re: [swift-evolution] [Proposal] Associated Type and Generic One-to-One Mapping

There could be source-breaking implications for such a feature, especially with retroactive conformance. Therefore, I think this could be very tricky and I'd want to be convinced that the benefits are very great to risk such a disturbance. Here, I think the problem is rather mild, and here's why:

Re: [swift-evolution] [Pitch] `let` in protocols

I think there might be some merit to this pitch, since you brought up a particular weak spot. I’d have to see what other people say about this, but it would seem that having the ability to explicitly mark something as constant for a given protocol implementation. However, I would propose a

[swift-evolution] [Proposal] Associated Type and Generic One-to-One Mapping

Hello Swift Evolution, This may have already been discussed before, but I just came across a bothersome language aspect which reminded me to propose a solution. Currently, if we want to add generics to a protocol the only way to do so is with associated types. I am quite fine with the current

[swift-evolution] [Pitch] `let` in protocols

Hello Swift Evolution, I’m bumping into an annoying problem with protocols. In a class or struct it is common to have a `let` instance variable and assign it in `init`. Unfortunately there is no way to translate this into a protocol with init in an extension. If attempting to set the variable

Re: [swift-evolution] ability to derive a class from a struct or other value type

Sent from my iPhone > On 23 Jun 2017, at 21:08, Haravikk via swift-evolution > wrote: > > >> On 23 Jun 2017, at 16:20, Mike Kluev wrote: >> >> on Fri Jun 23 05:26:11 CDT 2017 Haravikk swift-evolution at haravikk.me >> wrote: >> >> > Not

Re: [swift-evolution] ability to derive a class from a struct or other value type

On Fri, Jun 23, 2017 at 10:28 AM Mike Kluev wrote: > On 23 June 2017 at 18:31, Tony Allevato wrote: > >> >> Imagine something like this: >> >> struct BaseStruct { ... } >> class ExtendsStruct: BaseStruct { ... } >> >> func foo(x: BaseStruct) { ...

Re: [swift-evolution] ability to derive a class from a struct or other value type

> On 23 Jun 2017, at 16:20, Mike Kluev wrote: > > on Fri Jun 23 05:26:11 CDT 2017 Haravikk swift-evolution at haravikk.me > wrote: > > > Not sure what you mean by added indirection here, the following seems > > perfectly straightforward to me: > >

Re: [swift-evolution] [Announcement] Godbolt Compiler Explorer adds Swift support

I have a Vim plugin that does basically the same thing. It would just be nice to have it in something like Godbolt so you can share with others (and especially if it can highlight the SIL corresponding with a given line like it does for assembly). -Kevin Ballard On Fri, Jun 23, 2017, at 01:35 AM,

Re: [swift-evolution] ability to derive a class from a struct or other value type

On 23 June 2017 at 18:31, Tony Allevato wrote: > > Imagine something like this: > > struct BaseStruct { ... } > class ExtendsStruct: BaseStruct { ... } > > func foo(x: BaseStruct) { ... } > func bar(x: inout BaseStruct) { ... } > > var x = ExtendsStruct(...) > foo(x) >

Re: [swift-evolution] ability to derive a class from a struct or other value type

On Thu, Jun 22, 2017 at 5:15 PM Mike Kluev wrote: > On 23 June 2017 at 02:43, Tony Allevato > wrote: > >> There's been talk about "protocol forwarding" that I think would achieve >> a lot of these goals, without the sharp edges involved trying to

Re: [swift-evolution] ability to derive a class from a struct or other value type

on Fri Jun 23 05:26:11 CDT 2017 Haravikk swift-evolution at haravikk.me wrote: > Not sure what you mean by added indirection here, the following seems perfectly straightforward to me: > > protocol Foo { > var someValue:Int { get set } > func a() -> Any? > } > > extension Foo { > func a() ->

Re: [swift-evolution] Revisiting SE-0110

Hi, thanks for the answer. >> …by showing code that’s marginally different from each other, like one more >> nesting of parentheses, or one less label for a parameter. It seems to me >> that distinctions like these are just important at the compiler level, but >> not particularly useful from

Re: [swift-evolution] Revisiting SE-0110

Hi Elviro, > On 23. Jun 2017, at 13:46, Elviro Rocca via swift-evolution > wrote: [snip] > …by showing code that’s marginally different from each other, like one more > nesting of parentheses, or one less label for a parameter. It seems to me > that distinctions

Re: [swift-evolution] [pitch] composition as part of the language

This sounds similar to automatic protocol forward, have you looked into prior discussions on that topic here? Nevin On Thu, Jun 22, 2017 at 10:56 PM, Jay Abbott via swift-evolution < swift-evolution@swift.org> wrote: > Let's take a quick look at how we can achieve very simple compile-time >

Re: [swift-evolution] [Pitch] Object aliases

This sounds similar to lenses. Have you looked at previous lens discussions on-list? Nevin On Fri, Jun 23, 2017 at 3:28 AM, Daryle Walker via swift-evolution < swift-evolution@swift.org> wrote: > I started a thread earlier this week about strong type-aliases and object > aliases. Here’s a

Re: [swift-evolution] Revisiting SE-0110

This has been a very hard discussion to follow, even for a programmer that mostly just silently reads these threads to get a general understanding of what's going on in the community. There's an overwhelming amount of messages that point out potential bugs and unexpected behavior by showing

Re: [swift-evolution] ability to derive a class from a struct or other value type

> On 22 Jun 2017, at 22:28, Mike Kluev via swift-evolution > wrote: > > On Wed, 21 Jun 2017 15:04:46 David Moore > wrote: > > > This would be a bit counter-intutivie in my opinion, and it’s already > > possible > > with the language today. First

Re: [swift-evolution] ability to derive a class from a struct or other value type

What you're really after isn't "inheriting" from structs, you want to easily "compose" your classes (or structs) using the implementation from other implementation structs (components). I made a separate post all about this - how to make composition part of the language. On Fri, 23 Jun 2017 at

Re: [swift-evolution] [Announcement] Godbolt Compiler Explorer adds Swift support

If you're interested in just having a look at SIL output, then I put a very basic GUI wrapper around invocations of swiftc -emit-sil and friends: https://github.com/alblue/SILInspector It also supports piping them through the demangler and whether or not

[swift-evolution] [Pitch] Object aliases

I started a thread earlier this week about strong type-aliases and object aliases. Here’s a fuller proposal on object aliases. Feature name Proposal: SE- Authors: Daryle Walker , Author 2 Review Manager: TBD Status: Awaiting