Re: [swift-evolution] Ad hoc enums / options

> On Jun 2, 2016, at 5:05 AM, Christopher Kornher via swift-evolution > wrote: > > >> On Jun 1, 2016, at 7:48 PM, Ricardo Parada via swift-evolution >> > wrote: >> >> >> On May 31, 2016, at 3:04 PM,

Re: [swift-evolution] [Returned for Revision] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

Excellent. I put together a PR with a revised proposal containing the core team's recommended approach. If anyone is curious they can see it here: https://github.com/austinzheng/swift-evolution/blob/ef6adbe0fe09bff6c44c6aa9d73ee407629235ce/proposals/0095-any-as-existential.md

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Yes but, if they weren’t functions now, what would be the best design? How many Swift developers will be using this functionality? Less than 1%? I trust Dave’s judgement because he is in that small group. > On 2 Jun 2016, at 3:27 PM, Xiaodi Wu wrote: > > On Thu, Jun 2,

Re: [swift-evolution] Ad hoc enums / options

> On Jun 1, 2016, at 11:20 PM, Vladimir.S wrote: > > OK, I understand most of your points and feel the same regarding the proposed > feature... but: > > > .. the compiler does not like when we define the same thing twice, and thse > > short form amount to doing what he does

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

On Thu, Jun 2, 2016 at 12:24 AM, Patrick Smith wrote: > I really like this idea. This IMO is lower level functionality than > `type(of:)` (née dynamicType), so I think it makes sense for it to be > grouped under its own domain, the MemoryLayout type. > > Plus MemoryLayout can

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Using MemoryLayout is a much bigger change than the simple name changes being pitched here. I'm not ruling it out, but it may be deferred or additive as the 3.0 timeline allows and the core team decides. For now, my suggested design (strongly based on Wux's feedback and the previous thread

Re: [swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

On Jun 1, 2016, at 9:28 PM, Jacob Bandes-Storch wrote: > > On imported Objective-C API, the core team did a quick study of the Cocoa > APIs and found that most closure/block parameters are escaping in practice. > As such, the core team feels that it isn’t overly burdensome

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

I really like this idea. This IMO is lower level functionality than `type(of:)` (née dynamicType), so I think it makes sense for it to be grouped under its own domain, the MemoryLayout type. Plus MemoryLayout can be extended with new convenience methods. I’m fine with those old methods being

Re: [swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

> On Jun 1, 2016, at 9:22 PM, Trent Nadeau wrote: > > I'd like to write this proposal. Go for it! Thanks, -Chris > > On Thu, Jun 2, 2016 at 12:11 AM, Chris Lattner via swift-evolution > > wrote: > On Jun 1,

Re: [swift-evolution] [Returned for Revision] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On Jun 1, 2016, at 9:53 PM, Austin Zheng wrote: > > This was indeed a very thorough review by the core team. I'll prepare a v2 > proposal with this feedback taken into account so we can continue moving > things along. > > One quick question - is making whatever

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 1, 2016, at 11:10 PM, Xiaodi Wu wrote: > > On Thu, Jun 2, 2016 at 12:03 AM, Jacob Bandes-Storch > wrote: > If it's worth continuing the discussion in this thread, I rather like the > MemoryLayout.size idea. For

Re: [swift-evolution] Ad hoc enums / options

Yes, great point! I think this is a sign it’s better to just have one way with an enum, so there’s no deciding on which method to use, or reluctance to switch away from ad hoc enums because they felt nicer initially. And enums aren’t that much to write. With the addition of a macro system in

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

On Thu, Jun 2, 2016 at 12:03 AM, Jacob Bandes-Storch wrote: > If it's worth continuing the discussion in this thread, I rather like the > MemoryLayout.size idea. For discoverability, we might want to have > @availability(*, unavailable, message: "use MemoryLayout.size, etc.")

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

On Wed, Jun 1, 2016 at 11:55 PM, Xiaodi Wu wrote: > On Wed, Jun 1, 2016 at 11:28 PM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote: > >> Upon accepting SE-0098, the core team renamed the proposed stdlib >> function from dynamicType() to type(of:).

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 1, 2016, at 10:55 PM, Xiaodi Wu wrote: > > On Wed, Jun 1, 2016 at 11:28 PM, Erica Sadun via swift-evolution > > wrote: > Upon accepting SE-0098, the core team renamed the proposed stdlib function > from

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

If it's worth continuing the discussion in this thread, I rather like the MemoryLayout.size idea. For discoverability, we might want to have @availability(*, unavailable, message: "use MemoryLayout.size, etc.") public init(){}. Jacob On Wed, Jun 1, 2016 at 9:55 PM, Xiaodi Wu via swift-evolution

Re: [swift-evolution] Ad hoc enums / options

> Am 31.05.2016 um 21:04 schrieb Erica Sadun via swift-evolution > : > > >> On May 31, 2016, at 12:35 PM, Matthew Johnson wrote: >> >> I think I'm -1 on this. It makes things easier for the implementer of the >> function and harder for

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

On Wed, Jun 1, 2016 at 11:28 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > Upon accepting SE-0098, the core team renamed the proposed stdlib function > from dynamicType() to type(of:). They write, "The core team recognizes > that this means that we should probably

Re: [swift-evolution] [Returned for Revision] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

This was indeed a very thorough review by the core team. I'll prepare a v2 proposal with this feedback taken into account so we can continue moving things along. One quick question - is making whatever syntax is chosen for Swift 3 "forward-compatible" with a future generalized existential

[swift-evolution] [Returned for Revision] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md Hello Swift Community, The review of SE-0095: "Replace protocol syntax with Any" ran from May 24…30, 2016. The proposal is returned with revision requested - ideally the

Re: [swift-evolution] Ad hoc enums / options

I don't understand this. All of what you said applies to structs and does not apply to tuples. What makes it fundamentally impossible to have a "tuple-like enum"? Félix > Le 1 juin 2016 à 20:56:27, L. Mihalkovic via swift-evolution > a écrit : > > > > On Jun 1,

Re: [swift-evolution] Working with enums by name

> Brent, for needing "both Int and Double values" there is a proposal to add > tuples instead of the current raw values or allowing assessor properties per > case, you should check those out. Perhaps this could also be used to > cryptoghaphically sign a raw value but I'm not sure. I know; I

Re: [swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

On Wed, Jun 1, 2016 at 9:11 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > On Jun 1, 2016, at 9:02 PM, Chris Lattner wrote: > > 2) For noescape, the core team feels that the right solution is for > closure arguments to *default* to noescape, which

[swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Upon accepting SE-0098, the core team renamed the proposed stdlib function from dynamicType() to type(of:). They write, "The core team recognizes that this means that we should probably resyntax the existing sizeof/strideof functions, but that should be a follow-on discussion." Follow on

Re: [swift-evolution] [Pitch] #warning

> On Jun 1, 2016, at 10:54 AM, Jordan Rose via swift-evolution > wrote: > >> >> On May 29, 2016, at 13:20, Chris Lattner via swift-evolution >> > wrote: >> >>> On May 29, 2016, at 12:58 PM, Erica Sadun

Re: [swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

+1. It would be great to get this reviewed and in for Swift 3. Austin > On Jun 1, 2016, at 9:22 PM, Trent Nadeau via swift-evolution > wrote: > > I'd like to write this proposal. > > On Thu, Jun 2, 2016 at 12:11 AM, Chris Lattner via swift-evolution >

Re: [swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

I'd like to write this proposal. On Thu, Jun 2, 2016 at 12:11 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > On Jun 1, 2016, at 9:02 PM, Chris Lattner wrote: > > 2) For noescape, the core team feels that the right solution is for > closure

Re: [swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

On Jun 1, 2016, at 9:02 PM, Chris Lattner wrote: > 2) For noescape, the core team feels that the right solution is for closure > arguments to *default* to noescape, which means that the attribute we should > really need is @escaping. To provide some more details, this

[swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0097-negative-attributes.md Hello Swift Community, The review of SE-0097: "Normalizing naming for "negative" attributes" ran from May 24…30, 2016. The proposal is *rejected* for Swift 3. The core team agrees with

Re: [swift-evolution] Ad hoc enums / options

> On Jun 1, 2016, at 11:38 PM, Tony Allevato wrote: > > I find myself agreeing with the idea that ad hoc enums are to enums as > structs are to tuples. Based on that analogy, why should an ad hoc enum > *need* a name (autogenerated or otherwise) any more than a tuple

[swift-evolution] [Accepted with Revision] SE-0098: Converting dynamicType from a property to an operator

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0096-dynamictype.md Hello Swift Community, The review of SE-0098: "Converting dynamicType from a property to an operator" ran from May 24…30, 2016. The proposal is *accepted* for Swift 3. The feedback on the

[swift-evolution] [Rejected] SE-0098: Lowercase didSet and willSet for more consistent keyword casing

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0098-didset-capitalization.md Hello Swift Community, The review of SE-0098: "Lowercase didSet and willSet for more consistent keyword casing" ran from May 24…30, 2016. The proposal is *rejected* for Swift 3. The

Re: [swift-evolution] Ad hoc enums / options

What if (.Fit | .Fill) was just a shorthand for enums that you could use anywhere, like a tuple type? let foo: (.Fit | .Fill) = .Fit let bar: (.Fit | .Fill) = .Fill let frob = cond ? foo : bar // foo and bar have the same type You could typealias it too. Félix > Le 1 juin 2016 à 20:05:06,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On Jun 1, 2016, at 14:18, Austin Zheng wrote: > > I'd also like to express my support for the proposal to delineate generic and > existential syntax: all existentials must be written with Any<...>; generic > type constraints cannot use it. I hope this will make it

Re: [swift-evolution] Ad hoc enums / options

> On Jun 1, 2016, at 7:48 PM, Ricardo Parada via swift-evolution > wrote: > > > On May 31, 2016, at 3:04 PM, Erica Sadun via swift-evolution > > wrote: > >> let _ = scaleAndCropImage(image: myImage,

Re: [swift-evolution] Ad hoc enums / options

> On 2 Jun 2016, at 7:38 AM, Tony Allevato via swift-evolution > wrote: > > Would those who dislike ad hoc enums argue that this also shouldn't be > allowed: > > func foo(bar: (x: Int, y: Int)) {} > let t: (x: Int, y: Int) = (x: 5, y: 5) I would argue that

Re: [swift-evolution] Ad hoc enums / options

> On Jun 1, 2016, at 5:38 PM, Tony Allevato via swift-evolution > wrote: > > we could consider allowing this: > > func foo(bar: (.fit | .fill)) { > baz(bar: bar) > } > func baz(bar: (.fit | .fill | .florp) { ... } > > In other words, an ad hoc

Re: [swift-evolution] Ad hoc enums / options

> On May 31, 2016, at 3:04 PM, Erica Sadun via swift-evolution > wrote: > > let _ = scaleAndCropImage(image: myImage, toSize: size, operation: .fill) > > You would not be able to assign `.fill` to a variable and use that for the > operation value. This is my

Re: [swift-evolution] Ad hoc enums / options

Sent from my iPad > On Jun 1, 2016, at 5:02 PM, Vladimir.S via swift-evolution > wrote: > > > in other words, we could consider allowing this: > >func foo(bar: (.fit | .fill)) { > > baz(bar: bar) > >} > >func baz(bar: (.fit | .fill | .florp) { ...

Re: [swift-evolution] Ad hoc enums / options

Sent from my iPad > On Jun 1, 2016, at 4:38 PM, Tony Allevato via swift-evolution > wrote: > > I find myself agreeing with the idea that ad hoc enums are to enums as > structs are to tuples. Based on that analogy, why should an ad hoc enum > *need* a name

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

Sent from my iPad > On Jun 1, 2016, at 4:18 PM, Austin Zheng via swift-evolution > wrote: > > After thinking about this topic for the past few days, I'd like to throw in > my support for "Any<>" as well. It's one magic construct to learn, looks like > a type, has

Re: [swift-evolution] [Pitch] #warning

On Jun 1, 2016, at 3:56 AM, Jeremy Pereira via swift-evolution wrote: >> One may argue that the comment-based markings can be handled by the IDE, but >> IMO transferring language features onto IDE is wrong. These comments do not >> appear anywhere within the log when

Re: [swift-evolution] Ad hoc enums / options

A single member version of this could be useful, too. Has anyone else here ever found themself trying to think of an argument label for an init method, just to ensure it has a unique signature? This would be handy: *extension Foo {* *convenience init( _ kind:(.DiskBased) ){* *

Re: [swift-evolution] Ad hoc enums / options

On Wed, Jun 1, 2016 at 3:02 PM Vladimir.S wrote: > > in other words, we could consider allowing this: > >func foo(bar: (.fit | .fill)) { > > baz(bar: bar) > >} > >func baz(bar: (.fit | .fill | .florp) { ... } > > > > In other words, an ad hoc enum T can

Re: [swift-evolution] Working with enums by name

Brent, for needing "both Int and Double values" there is a proposal to add tuples instead of the current raw values or allowing assessor properties per case, you should check those out. Perhaps this could also be used to cryptoghaphically sign a raw value but I'm not sure. As for working with

Re: [swift-evolution] Ad hoc enums / options

> in other words, we could consider allowing this: >func foo(bar: (.fit | .fill)) { > baz(bar: bar) >} >func baz(bar: (.fit | .fill | .florp) { ... } > > In other words, an ad hoc enum T can be used wherever an ad hoc enum U is > expected if T ⊆ U. Can't agree with this. Just

Re: [swift-evolution] Ad hoc enums / options

I support the original proposal. My assumption is that (.fit|.fill) is the name of a type that can be used anywhere types can be named. I think the concern about duplicates is misplaced. If the same developer creates the scaleAndCrop function and the rect function, they may decide to extract the

Re: [swift-evolution] Working with enums by name

Can't agree with Brent's opinion. For me the proposed init(caseName:String) and .caseName property for enum case - seems like base feature that enum type must to have. As for string as raw value for enum, please find this example: enum E: String { case one = "One" case two = "Two" }

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

I imagine you can use a combination of: *Deferred for Future Discussion*: https://github.com/apple/swift-evolution#deferred-for-future-discussion *Accepted proposals which do not have a complete implementation:*

Re: [swift-evolution] Ad hoc enums / options

I find myself agreeing with the idea that ad hoc enums are to enums as structs are to tuples. Based on that analogy, why should an ad hoc enum *need* a name (autogenerated or otherwise) any more than a tuple needs a name? Would those who dislike ad hoc enums argue that this also shouldn't be

Re: [swift-evolution] Working with enums by name

Oops. I have wanted this feature and I have created `name` methods for non-String enums numerous times (whether I had to or not, I guess). If there is a formal proposal for this, I could not find it. I am obviously not familiar with the entire proposal but this is a feature that I have wanted

Re: [swift-evolution] Ad hoc enums / options

OK, I understand most of your points and feel the same regarding the proposed feature... but: > .. the compiler does not like when we define the same thing twice, and thse short form amount to doing what he does not let us do. .. > .. if we use an annotation that lets it know that "it is not

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

After thinking about this topic for the past few days, I'd like to throw in my support for "Any<>" as well. It's one magic construct to learn, looks like a type, has the visual delineation, and shares continuity with both protocol<> and Any today. I'd also like to express my support for the

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

> UIBezierPath is shared for all instances of the enum case. So stored > properties are stored per case, not per instance (you have associated > values for per instance values). > >> that isn't really what this syntax suggests is happening > > Please explain what makes you think that way.

Re: [swift-evolution] Working with enums by name

> This should work but feels like an ugly hack to me. What if I needed > the enum like this? > > | enum Size : Double { > | case Fit = 0.5 > | case Fill = 3.0 > | } What if you needed both Int and Double rawValues? What if you needed rawValues that were cryptographically signed?

Re: [swift-evolution] Working with enums by name

> On Jun 1, 2016, at 2:20 PM, Christopher Kornher via swift-evolution > > wrote: > >> On Jun 1, 2016, at 12:53 PM, Paul Cantrell via swift-evolution >> > wrote: >> >> This

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

> [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md > ] > > I’m late again to this one, but the discussion’s certainly still going. I’m > pretty strongly against the bare ‘A & B’ syntax, for a few reasons: > > - Swift doesn’t use ‘&’ for

Re: [swift-evolution] Ad hoc enums / options

> On Jun 1, 2016, at 6:51 PM, Vladimir.S wrote: > > Yes, I also can support the idea of autogenerated type name (like > Enum_fit_OR_fill) as long as it allows to do all the things we are discussing > here: declare (.fit|.fill) in function, use .fit on calling side, use >

Re: [swift-evolution] Working with enums by name

Enums outside frameworks will still rely on you as the programmer to know to which enum the string representation belongs to (it does so for the raw values) so I see no reason why the .caseName result should have the name of any underlying type the case belongs to. L On 1 June 2016 at 16:20,

Re: [swift-evolution] Working with enums by name

> On Jun 1, 2016, at 12:53 PM, Paul Cantrell via swift-evolution > wrote: > > Indeed, you’re quite right: verified that I get “Mars” even when the enum is > in a framework. > > It took a little digging to get back what I was thinking of: it’s when the > enum value

Re: [swift-evolution] Working with enums by name

Indeed, you’re quite right: verified that I get “Mars” even when the enum is in a framework. It took a little digging to get back what I was thinking of: it’s when the enum value is inside some other data structure that you get an annoyingly fully qualified name: enum CoinSide {

Re: [swift-evolution] [Pitch] #warning

> On May 29, 2016, at 13:20, Chris Lattner via swift-evolution > wrote: > >> On May 29, 2016, at 12:58 PM, Erica Sadun wrote: >> One could make a weak argument that #warning/#error/#message make a nice >> family of flexible alerts >> just

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

Hello David, Could you elaborate on this more? Seeing the possibilities of FSM's in Swift using its powerful enum and case pattern matching was one of the moments in which Swift started increasing its allure factor ;). Part 1 (background and theory):

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

It is of course true that all parts of a conditional statement have something in common with each other, namely that they are part of the same conditional statement. A problem definitely exists with the current syntax, which is that the de minimis semantic relationship you are showing is not the

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

Feel free to convince the core team to add such a list. ;) --  Adrian Zubarev Sent with Airmail Am 1. Juni 2016 um 19:17:25, Vladimir.S (sva...@gmail.com) schrieb: Do we have any 'feature' to not just throw away of proposals(and then scan mail list and remember), but put them in queue of

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

Do we have any 'feature' to not just throw away of proposals(and then scan mail list and remember), but put them in queue of proposals that should be reviewed after Swift 3 is released? Probably some list of such proposals on site, don't know. So I believe any proposal that would be raised

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> To fix any confusion between these I'd rather change the syntax of the > conditional let binding to something like `let x ?= x` or similar (which > has been proposed quite a few times on this list already). FWIW, I also think `if let one = two` is not descriptive enough about what is going

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

Given that Swift 3 is winding down, we are in a mode of declining PRs for proposals that don’t align with its goals. Please bring this back up for discussion this fall, thanks for understanding. Closed by Chris. Sad but we’ll have to wait a little longer for this change. --  Adrian Zubarev

Re: [swift-evolution] Ad hoc enums / options

Yes, I also can support the idea of autogenerated type name (like Enum_fit_OR_fill) as long as it allows to do all the things we are discussing here: declare (.fit|.fill) in function, use .fit on calling side, use (.fit|.fill) to declare temporary variable of type compatible with such function

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md ] I’m late again to this one, but the discussion’s certainly still going. I’m pretty strongly

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> Am 01.06.2016 um 03:47 schrieb Xiaodi Wu via swift-evolution > : > > Revisiting this conversation, it seems that most of the design space has been > thoroughly explored. I think all suggestions presented so far boil down to > these: > > Q: How is an arbitrary

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> Am 01.06.2016 um 00:26 schrieb Paul Cantrell via swift-evolution > : > > I certainly am warm to that myself, although I’m also sympathetic to what > Chris wrote about the inconsistency it introduces: > > let x = optionalX!, y = optionalY! // Works! >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> Am 31.05.2016 um 23:01 schrieb Haravikk via swift-evolution > : > > >> On 31 May 2016, at 18:57, Erica Sadun via swift-evolution >> wrote: >> >> * Should `where` clauses be allowed where the contents of the where clause >> have no

Re: [swift-evolution] Variadic generics discussion

This is good to know, thanks for the clarification! Austin > On Jun 1, 2016, at 9:38 AM, Joe Groff wrote: > > A regular value is a 1-tuple of itself. In the type system, we know what > abstraction level a value expects to work at. It shouldn't be a problem for a > variadic

Re: [swift-evolution] Ad hoc enums / options

> On Jun 1, 2016, at 8:58 AM, L. Mihalkovic > wrote: > > > >> On Jun 1, 2016, at 2:38 PM, Vladimir.S via swift-evolution >> wrote: >> >>> On 01.06.2016 11:00, Austin Zheng wrote: >>> Tuples are a structural type, they are described

Re: [swift-evolution] Variadic generics discussion

> On Jun 1, 2016, at 9:35 AM, Austin Zheng wrote: > > >> On Jun 1, 2016, at 6:18 AM, Joe Groff wrote: >> >> >>> On May 31, 2016, at 6:49 PM, Austin Zheng wrote: >>> >>> I agree that this is a better design for Swift than the

Re: [swift-evolution] Variadic generics discussion

> On Jun 1, 2016, at 6:18 AM, Joe Groff wrote: > > >> On May 31, 2016, at 6:49 PM, Austin Zheng wrote: >> >> I agree that this is a better design for Swift than the monstrosity I >> started out with. >> >> The "biggest" technical challenge I see is

Re: [swift-evolution] [swift-users] UnsafeMutablePointer vs. UnsafeMutablePointer

So basically if my application terminates without errors or crashes I can be sure that the OS will free any memory it used. Now I feel safe using UnsafeMutablePointers in swift :) --  Adrian Zubarev Sent with Airmail Am 1. Juni 2016 um 18:19:01, Austin Zheng (austinzh...@gmail.com) schrieb:

Re: [swift-evolution] Working with enums by name

This will not print the name of case : enum E: CustomStringConvertible { case one, two var description: String {return "haha"} } print(E.one) So, for me, it seems like the good idea to have a standard(and built-in) way to convert string<->case i.e. to have let e = E(caseName:

Re: [swift-evolution] Ad hoc enums / options

The only problem with this proposal is to consider them ad-hoc enums... If we view them as having nothing ad-hoc about them and the thing to be a simple sugaring exercise, then I think all the opositions on grounds of breaking the language disapear. It still does not mean it should be done if

Re: [swift-evolution] Ad hoc enums / options

> On Jun 1, 2016, at 2:38 PM, Vladimir.S via swift-evolution > wrote: > >> On 01.06.2016 11:00, Austin Zheng wrote: >> Tuples are a structural type, they are described entirely by the fact >> that they are a tuple, plus their contained types. >> >> Enum cases are

Re: [swift-evolution] [Pitch] Expose assert configuration functions in standard library

> On Jun 1, 2016, at 9:15 AM, Erica Sadun wrote: > > Or, to be honest: > > /// Offers user-facing public assert configuration test > @_transparent > public > func isDebugAssertConfiguration() -> Bool { > return _isDebugAssertConfiguration() > } > > which covers, I

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

I'm not much fond of Java enums but then Java also doesn't have structs so I think enums there were created to be a mix of structs and enums and that's why you can do all the things you mention on your list. That said: - The tuple typed enum approach is the closest thing we discussed to

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

> On Jun 1, 2016, at 9:48 AM, David Waite via swift-evolution > wrote: > > One thing I did often in Java (and miss in Swift) is using their enums to > build state machines or implement command patterns for common commands. > > Java enums are a sealed set of

Re: [swift-evolution] [Pitch] Expose assert configuration functions in standard library

Or, to be honest: /// Offers user-facing public assert configuration test @_transparent public func isDebugAssertConfiguration() -> Bool { return _isDebugAssertConfiguration() } which covers, I believe, about 98% of the demand for this feature -- E > On May 31, 2016, at 11:21 PM, Brent

Re: [swift-evolution] Working with enums by name

IIRC, string interpolation prepends the module name if the enum belongs to a module: “MyLib.Mars” instead of just “Mars”. It’s also been a source of compiler crashes, at least in the past. Those two factors forced me into this ugliness:

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

Sent from my iPad > On Jun 1, 2016, at 9:48 AM, David Waite via swift-evolution > wrote: > > One thing I did often in Java (and miss in Swift) is using their enums to > build state machines or implement command patterns for common commands. > > Java enums are a

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

One thing I did often in Java (and miss in Swift) is using their enums to build state machines or implement command patterns for common commands. Java enums are a sealed set of subclasses of the enum base type with (hopefully) immutable, singleton instances. So you can do fun things like: -

Re: [swift-evolution] [Proposal] Shorthand Argument Renaming

Not for or against a change in shorthand/defaulted names in general, but leading-dot in particular. Leading dot already means something (access a static property/method of the expected type, including enum types). This usage has nothing to do with that existing behavior of the syntax other

Re: [swift-evolution] Ad hoc enums / options

Lots of people have added their 2¢ now, you probably have about 10 dollars worth, but here goes. While it looks nice and short, I think it has a range of drawbacks: - It’s not a real type that can participate in protocols or extensions. - Discourages DRY coding, because some people will think

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

I’ve always had a funny feeling about the `where` keyword in `if` statements. It feels like it adds structure, but it’s not the most flexible of keywords. I sometimes find myself writing to match the structure it wants rather than the other way around. I rather like this proposal. What if

Re: [swift-evolution] Variadic generics discussion

> On Jun 1, 2016, at 8:29 AM, Joe Groff wrote: > >> >> On Jun 1, 2016, at 6:26 AM, Matthew Johnson wrote: >> >>> >>> On Jun 1, 2016, at 8:18 AM, Joe Groff via swift-evolution >>> wrote: >>> On May 31, 2016,

Re: [swift-evolution] Variadic generics discussion

> Perhaps inout params of type T could be somehow passed as a pair (T, (T) -> > ()), where the first item is the input value and the second item is a > writeback function representing the 'out' part of inout. The simplest solution, I think, is to require the entire splatted tuple to be `inout`

Re: [swift-evolution] Variadic generics discussion

> On Jun 1, 2016, at 6:26 AM, Matthew Johnson wrote: > >> >> On Jun 1, 2016, at 8:18 AM, Joe Groff via swift-evolution >> wrote: >> >>> >>> On May 31, 2016, at 6:49 PM, Austin Zheng wrote: >>> >>> I agree that this

Re: [swift-evolution] Variadic generics discussion

> On Jun 1, 2016, at 8:18 AM, Joe Groff via swift-evolution > wrote: > >> >> On May 31, 2016, at 6:49 PM, Austin Zheng wrote: >> >> I agree that this is a better design for Swift than the monstrosity I >> started out with. >> >> The

Re: [swift-evolution] Variadic generics discussion

> On May 31, 2016, at 6:49 PM, Austin Zheng wrote: > > I agree that this is a better design for Swift than the monstrosity I started > out with. > > The "biggest" technical challenge I see is being able to type a reduction > sort of operator on a heterogenous tuple

Re: [swift-evolution] Ad hoc enums / options

> Le 1 juin 2016 à 02:55, Austin Zheng via swift-evolution > a écrit : > > Maybe it's overkill. My personal opinion is that breaking the symmetry of the > language like this (are there any other types of function arguments that > cannot be passed as either

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Apologies for going off that tangent earlier. > On May 31, 2016, at 7:47 PM, Xiaodi Wu via swift-evolution > wrote: > > Revisiting this conversation, it seems that most of the design space has been > thoroughly explored. I think all suggestions presented so far boil

Re: [swift-evolution] Ad hoc enums / options

On 01.06.2016 11:00, Austin Zheng wrote: Tuples are a structural type, they are described entirely by the fact that they are a tuple, plus their contained types. Enum cases are not individual types; that precedent exists nowhere in Swift. You can't (yet) build a structural type out of something

Re: [swift-evolution] Ad hoc enums / options

> On 1 Jun 2016, at 12:35, Leonardo Pessoa wrote: > > Unions have been discussed earlier in this group and I personally > think this is an issue better solved using function overloading. Sorry, my intention wasn’t to debate them, I was just using them as an example of a

  1   2   >