Re: [swift-evolution] a few initializer proposals

Strongly +1 on proposals #1 and #2. Cautiously +1 on #3 (I’m not sure about side effects there). If #1 is already possible as Jon Shier says using an extension, I’d say it deserves promotion to be part of the language (e.g. Mike’s proposed `default init`), or at least should be made more discovera

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

Howdy, Matt Godbolt and I have added Swift support to his compiler explorer project https://swift.godbolt.org/ It let's you interactively explore assembly emitted by the Swift compiler. Right now, if you want the compiler to emit Intel syntax instructions, pass "-emit-assembly -Xllvm --x86-asm-s

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

Awesome! :) 3.1.1 is a great start — any plans to include recent nightly builds of the compiler, similar to IBM's Swift Sandbox ? On Thu, Jun 22, 2017 at 10:24 AM, Adam Nemecek via swift-evolution < swift-evolution@swift.org> wrote: > Howdy, > Matt Godbolt and

Re: [swift-evolution] a few initializer proposals

I think an even stronger change should be made for #1: instead of explicitly opting into not discarding the default initializer, you should have to explicitly opt out of keeping it with something like @nosynthesizedinit. Unless I’m missing something and there is a compelling reason to remove the

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

This is really cool! I second Jacob’s request for nightlies. Many things in the Swift compiler are architected similarly to Clang (inspired by Clang), so hopefully any features the explorer can do for C++ it could do for Swift as well. The swift compiler dump ASTs similarly to Clang with e.g.

Re: [swift-evolution] a few initializer proposals

On 22 June 2017 at 02:46, Jon Shier wrote: 1 can already be accomplished by moving the custom initializer into an > extension. > it can indeed. although if you need to create an extension just for this purpose it feels like a workaround, takes more lines and is less obvious, imho. plus if #3 is

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

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 of all, structs in Swift cannot be built upon. > Rather, I believe the intention is to use protocols for such a task. That’s what > the

Re: [swift-evolution] a few initializer proposals

These issues which you have raised have been discussed thoroughly on this list some time ago. It was distilled into a very well written proposal, SE-0018, that was evaluated and deferred. I would recommend that you and all people who are interested in this topic review the initial pitch and the sub

Re: [swift-evolution] a few initializer proposals

On 23 June 2017 at 00:36, Brian King > wrote: > A similar syntax has already been proposed and has been `deferred`. There > are a few other links to discussion in the proposal. > > https://github.com/apple/swift-evolution/blob/master/ > proposals/0018-flexible-memberwise-initialization.md > thank

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

There's been talk about "protocol forwarding" that I think would achieve a lot of these goals, without the sharp edges involved trying to define inheritance between a class and a struct. The proposed feature would eliminate the boilerplate you're talking about. I'm on my phone so I can't pull up l

Re: [swift-evolution] a few initializer proposals

On 23 June 2017 at 02:39, Mike Kluev wrote: > > if a single private var has no implicit / explicit default value then > default member wise initialiser is not created (#change) and attempt to > opt-in to have one gives an error. let's call it proposal #5. this > particular one is not a backward c

[swift-evolution] [Revised and review extended] SE-0180 - String Index Overhaul

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md The review of “SE-0180 - String Index Overhaul” ran from June 4…8, 2017. Feedback on the pr

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

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 define > inheritance between a class and a struct. The proposed feature would > eliminate the boilerplate y

Re: [swift-evolution] [swift-evolution-announce] [Revised and review extended] SE-0180 - String Index Overhaul

> https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md Given the discussion in the original thread about potentially having Strings backed by something other than utf16 code units, I'm somewhat concerned about having this kind of vague `encodedOffset` that ha

Re: [swift-evolution] a few initializer proposals

On 23 June 2017 at 01:20, Xiaodi Wu > wrote: > These issues which you have raised have been discussed thoroughly on this > list some time ago. It was distilled into a very well written proposal, > SE-0018, that was evaluated and deferred. I would recommend that you and > all people who are interes

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

That's pretty cool. Any plans on adding support for looking at the SIL output? -Kevin Ballard On Thu, Jun 22, 2017, at 10:24 AM, Adam Nemecek via swift-evolution wrote:> Howdy, > Matt Godbolt and I have added Swift support to his compiler > explorer project> > https://swift.godbolt.org/ > > I

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

Let's take a quick look at how we can achieve very simple compile-time composition in Swift today. I want to define a `Doorman` behaviour, and I want to compose it from other behaviours that are shared by some of my other staff types: ```swift protocol Greeter { func greet() } protocol Farewe