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

See https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019825.html as well as https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019908.html https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019827.html https://lists.swift.org/piperma

Re: [swift-evolution] [Proposal] Enum subsets

It seems like it would make sense to model enum subsets as a subtype relationship. Is the core team planning on drawing up a structs/enums subtyping proposal later this year? Austin > On Jun 3, 2016, at 10:25 PM, Chris Lattner wrote: > > >> On Jun 3, 2016, at 2:35 PM, T.J. Usiyan via swift-

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 8:11 PM, Ben Rimmington wrote: > I think your original proposal is good, but just in case: > > [Currently] > >// Literal `7` is converted to `Swift.IntegerLiteralType` typealias. >UInt16(7) calls UInt16.init(_ value: Int) > > [Suggested] > >// Literal `7` is co

Re: [swift-evolution] [Proposal] Enum subsets

> On Jun 3, 2016, at 2:35 PM, T.J. Usiyan via swift-evolution > wrote: > > Since this seems to have some interest, I've made a gist. > > https://gist.github.com/griotspeak/963bc87a0c244c120264b11fb022d78c > We have frequent

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

There was also my suggestion for a function such as memoryLayout(of:) that returned an instance of a simple MemoryLayout struct which I believe is a bit different than the MemoryLayout generics approach. I’m not sure if that was expressly shot down or ruled out or not, though. l8r Sean > On J

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

In defense of MemoryLayout's "less clarity", the people who know enough to use that stuff won't have trouble understanding it. That said, while I like it, I'm mostly interested in sequestering this stuff away in a type as a step towards a some sort of vague macro system. Since that's obviously

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

If there's any interest in going down that road, it seems to me that the only viable option is to allow subsets to be convertible to their superset. Items of (.foo | .bar) would be convertible to (.foo | .bar | .baz), but not the opposite (and not necessarily, although preferably, through a simp

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

I think your original proposal is good, but just in case: [Currently] // Literal `7` is converted to `Swift.IntegerLiteralType` typealias. UInt16(7) calls UInt16.init(_ value: Int) [Suggested] // Literal `7` is converted to `UInt16.IntegerLiteralType` associatedtype. UInt16(7) c

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

Looks good! I definitely like the ‘memory’ prefixes for the functions. I appreciate that stating the name earlier with the functions vs MemoryLayout.blah is easier to read. It feels a little bit of a shame to make `memorySize(ofType:)` longer than `memorySize(of:)`, as I think it will be used m

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 7:08 PM, Matthew Johnson wrote: >> On Jun 3, 2016, at 8:11 PM, John McCall wrote: >> >>> On Jun 3, 2016, at 5:13 PM, Matthew Johnson wrote: >>> On Jun 3, 2016, at 6:23 PM, John McCall wrote: >>> >> On Jun 3, 2016, at 4:07 PM, David Sweeris wrote: >> On Jun 3, 201

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 8:11 PM, John McCall wrote: > >> On Jun 3, 2016, at 5:13 PM, Matthew Johnson wrote: >> On Jun 3, 2016, at 6:23 PM, John McCall wrote: >> > On Jun 3, 2016, at 4:07 PM, David Sweeris wrote: > On Jun 3, 2016, at 16:17, Matthew Johnson via swift-evolution > wro

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 5:31 PM, Ben Rimmington via swift-evolution > wrote: > John McCall wrote: > >> I think that's a very promising way of thinking about literals. Writing >> a literal creates a notional value whose type is the informal, infinite- >> precise type of all integer/FP/collection/et

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 5:13 PM, Matthew Johnson wrote: > On Jun 3, 2016, at 6:23 PM, John McCall wrote: > On Jun 3, 2016, at 4:07 PM, David Sweeris wrote: On Jun 3, 2016, at 16:17, Matthew Johnson via swift-evolution wrote: Using an external parameter label in a declar

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

John McCall wrote: > I think that's a very promising way of thinking about literals. Writing > a literal creates a notional value whose type is the informal, infinite- > precise type of all integer/FP/collection/etc. literals, which (1) can be > implicitly converted to any type that implements th

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

Sent from my iPad On Jun 3, 2016, at 6:23 PM, John McCall wrote: >>> On Jun 3, 2016, at 4:07 PM, David Sweeris wrote: >>> On Jun 3, 2016, at 16:17, Matthew Johnson via swift-evolution >>> wrote: >>> >>> Using an external parameter label in a declaration and allowing it to be >>> omitted a

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

Sent from my iPad > On Jun 3, 2016, at 6:44 PM, Erica Sadun wrote: > > >> On Jun 3, 2016, at 5:20 PM, Greg Parker via swift-evolution >> wrote: >> What about the ABI? This sounds expensive to implement. >> >> Consider this set of ad-hoc enum types: >> >> (.a | .b) >> (.c | .d) >> >> Na

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

Sent from my iPad > On Jun 3, 2016, at 6:20 PM, Greg Parker wrote: > > >>> On Jun 1, 2016, at 5:42 PM, Matthew Johnson via swift-evolution >>> wrote: >>> On Jun 1, 2016, at 5:02 PM, Vladimir.S via swift-evolution wrote: in other words, we could consider allowing this

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

> On Jun 3, 2016, at 5:20 PM, Greg Parker via swift-evolution > wrote: > What about the ABI? This sounds expensive to implement. > > Consider this set of ad-hoc enum types: > > (.a | .b) > (.c | .d) > > Naive implementation: we'll represent these things as ints, with .a=1, .b=2, > .c=1,

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

I would be very interested in seeing your original proposal presented for formal review. Austin On 6/3/16, John McCall via swift-evolution wrote: >> On Jun 3, 2016, at 4:07 PM, David Sweeris wrote: >>> On Jun 3, 2016, at 16:17, Matthew Johnson via swift-evolution >>> wrote: >>> >>> Using an ex

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 4:07 PM, David Sweeris wrote: >> On Jun 3, 2016, at 16:17, Matthew Johnson via swift-evolution >> wrote: >> >> Using an external parameter label in a declaration and allowing it to be >> omitted at the call site does not feel like the right answer to me. I think >> we ca

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

> On Jun 1, 2016, at 5:42 PM, Matthew Johnson via swift-evolution > wrote: > >> 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:

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 16:17, Matthew Johnson via swift-evolution > wrote: > > Using an external parameter label in a declaration and allowing it to be > omitted at the call site does not feel like the right answer to me. I think > we can find a better way to present this syntactically. +elev

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

+1 I think the new guard/if/while grammar is an improvement. We have a limited number of ASCII punctuation characters, and the semicolon is currently underused in Swift. -- Ben _

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> I think our decision should be based upon which syntactic construct feels > least inconsistent with other similar syntactic constructs and therefore > feels the least arbitrary. Restricting the usage of a generic `Literal` type > to literal convertible initializers feels a little bit less arb

Re: [swift-evolution] [Proposal] Enum subsets

I like the idea, conceptually—having more set-like semantics for enums sounds like it would open up some interesting possibilities. (And I don't think we should limit ourselves to subsets either. Supersets are also interesting.) Things could get pretty tricky though, so there are a lot of gaps to

Re: [swift-evolution] [Proposal] Enum subsets

The syntax I described here has a number of problems, among them being: 1) Creating a supersets in the way described breaks down badly when the declarations exist within multiple modules. 2) The empty enum declaration is currently illegal and probably should be 3) The su

Re: [swift-evolution] [Proposal] Enum subsets

A few ideas: * Mention the pull request about member sets? * I'd try to give some more compelling use cases (Where a union type can be broadly applied across more specific uses, which then tend to narrow the applicable cases, and you want to limit (and compile check) those cases while inheritin

Re: [swift-evolution] [Proposal] Enum subsets

Since this seems to have some interest, I've made a gist. https://gist.github.com/griotspeak/963bc87a0c244c120264b11fb022d78c Introduction This proposal adds/creates syntax to allow ad hoc creation of enums whose members are strict subsets of explicitly defined enums. Swift-evolution thread: Dis

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 4:05 PM, Brent Royal-Gordon wrote: > >> I am not the only one who feels that way. Quoting Brent: >> >> "But if you're going to call `init(integerLiteral:)` like it's `init(_:)`, I >> don't think that's a good idea. Parameter labels are supposed to be >> significant; we d

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 3:17 PM, John McCall wrote: > >> On Jun 3, 2016, at 12:41 PM, Matthew Johnson > > wrote: >>> On Jun 3, 2016, at 1:36 PM, John McCall >> > wrote: >>> On Jun 2, 2016, at 6:48 PM, Matthew Johnson >>>

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

Discussion has more or less drawn down. Are there any further significant requests / issues that need addressing? Both standalone functions (my recommended approach) and the MemoryLayout struct approach (alternative, with reasons why I think it's not as ideal) are discussed in-proposal. Pull R

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> I am not the only one who feels that way. Quoting Brent: > > "But if you're going to call `init(integerLiteral:)` like it's `init(_:)`, I > don't think that's a good idea. Parameter labels are supposed to be > significant; we don't want to lose that.” > > I agree with this. That is the moti

Re: [swift-evolution] [Proposal] Enum subsets

I really like the idea behind this proposal. Some questions: - Would the enum 'slice' be a distinct type relative to the base enum? - On a related note, would shared cases between the sliced enum and the base enum be implicitly convertible? - If they aren't implicitly convertible between each oth

Re: [swift-evolution] [Proposal] Enum subsets

I really like this idea, a few comments I have: Would this subset be exhaustive within only the subset you’ve restricted it to? I’m hoping so! i.e- if I do a switch on LCDColors I assume I only have to provide three cases, but this doesn’t appear to be expressly mentioned. Do you envision this be

Re: [swift-evolution] [Proposal] Enum subsets

My only hesitation with using `enum LCDColors : Colors` is that that syntax usually signals extending a type and I am not sure whether I am advocating for the ability to add something to `LCDColors` without adding it to `Colors`. I envisioned it as 'simply a subset of cases' but that is probably ju

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 12:41 PM, Matthew Johnson wrote: >> On Jun 3, 2016, at 1:36 PM, John McCall > > wrote: >> >>> On Jun 2, 2016, at 6:48 PM, Matthew Johnson >> > wrote: >>> On Jun 2, 2016, at 6:51 PM, John McCall via swift-evolution >>>

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

On Fri, Jun 3, 2016 at 2:41 PM, Matthew Johnson wrote: > > On Jun 3, 2016, at 1:36 PM, John McCall wrote: > > On Jun 2, 2016, at 6:48 PM, Matthew Johnson > wrote: > On Jun 2, 2016, at 6:51 PM, John McCall via swift-evolution < > swift-evolution@swift.org> wrote: > > On Jun 2, 2016, at 4:33 PM,

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 8:51 PM, John McCall wrote: > >> On Jun 2, 2016, at 10:31 PM, L. Mihalkovic >> wrote: >>> On Jun 2, 2016, at 6:08 PM, John McCall via swift-evolution >>> wrote: >>> >>> The official way to build a literal of a specific type is to write the >>> literal in an explicitly-

Re: [swift-evolution] [Proposal] Enum subsets

Your original syntax makes LCDColors clearly a type. The typealias obscures the fact that a new type is being created. An alternative might be something like: ``` enum LCDColors : Colors { case red, green, blue } ``` or perhaps ``` enum LCDColors subset: Colors { case red, gre

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 1:36 PM, John McCall wrote: > >> On Jun 2, 2016, at 6:48 PM, Matthew Johnson > > wrote: >> On Jun 2, 2016, at 6:51 PM, John McCall via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> On Jun 2, 2016, at 4:33 PM, Xiaodi Wu

Re: [swift-evolution] [Pre-proposal] Forward/Reverse Only Indexing Methods

> On 1 Jun 2016, at 05:51, Thorsten Seitz wrote: > > I like this idea. The problem is that it would require that we have an > Index.NonNegativeDistance as argument to really make it statically safe. And > we would have to have methods producing these, probably as optional return > values. >

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 2, 2016, at 10:31 PM, L. Mihalkovic > wrote: > On Jun 2, 2016, at 6:08 PM, John McCall via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> The official way to build a literal of a specific type is to write the >> literal in an explicitly-typed context, like so: >>

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 2, 2016, at 6:48 PM, Matthew Johnson wrote: > On Jun 2, 2016, at 6:51 PM, John McCall via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >>> On Jun 2, 2016, at 4:33 PM, Xiaodi Wu >> > wrote: >>> The IntegerLiteral type idea might be worth explo

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 2, 2016, at 10:28 PM, Vladimir.S wrote: > > Like I said, the standard library and compiler conspire to make sure that > > easy cases like this are caught at compile time, but that would not help > > non-standard types that conform to IntegerLiteralConvertible. > > > > Also, even for sta

Re: [swift-evolution] [Proposal] Enum subsets

I don't have a problem with something as explicit as that. I was mostly avoiding adding keywords with my proposed syntax. I have basically no tie to the proposed syntax. TJ On Fri, Jun 3, 2016 at 12:32 PM, Christopher Kornher wrote: > This could be useful in categorizing and grouping within lar

Re: [swift-evolution] [Proposal] Enum subsets

This could be useful in categorizing and grouping within large enums ErrorType enums come to mind. Would there be any problem with making the subset more explicit? e.g. ``` swift enum Colors { case red, orange, yellow, green, blue, indigo, violet … } extension Colors {

Re: [swift-evolution] [Pitch] Unify preset static "initializers"

I believe that the change for UIColor.black and friends has already been accepted. I believe that it is the result of the guidelines but I didn't find a specific reference just now while looking. TJ On Fri, Jun 3, 2016 at 12:08 PM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote:

Re: [swift-evolution] Writing all protocol types with Any<> (was [Review] SE-0095)

> On Jun 2, 2016, at 23:24, Thorsten Seitz wrote: > > > > Am 02. Juni 2016 um 05:15 schrieb Jordan Rose via swift-evolution > : > >> >>> On Jun 1, 2016, at 14:18, Austin Zheng >> > wrote: >>> >>> I'd also like to express my support for the proposal to delineat

Re: [swift-evolution] [Pitch] Unify preset static "initializers"

CGRect.zero should IMHO be deprecated in favor of CGRect() instead, which makes it shorter and more "Swifty". But that's probably just my personal opinion and a bit off topic. Nevertheless .zero on CGRect is a Swift extension which is `static var`. There is currently no way to have static vars

Re: [swift-evolution] [Pitch] Unify preset static "initializers"

I feel that obviously UIColor.blackColor() should be transformed to UIColor.black property, but I'm not sure if this could be discussed in this mailing list(Swift evolution). (P.S. all your 3 emails were posted in list) On 03.06.2016 17:45, Bas Broek via swift-evolution wrote: Hi all, I was

[swift-evolution] [Pitch] Unify preset static "initializers"

Hi all, I was wondering the other day why "static initializers", as I will call them, are not unified: > CGRect.zero vs > UIColor.blackColor() - which will be UIColor.black() in Swift 3. ... which both do pretty much the same; they are used as convenience initialization for the specific type.

[swift-evolution] [Pitch] Unify preset static "initializers"

Hi all, I was wondering the other day why "static initializers", as I will call them, are not unified: > CGRect.zero vs > UIColor.blackColor() - which will be UIColor.black() in Swift 3. ... which both do pretty much the same; they are used as convenience initialization for the specific type.

[swift-evolution] [Pitch] Unify preset static "initializers"

Hi all, I was wondering the other day why "static initializers", as I will call them, are not unified: > CGRect.zero vs > UIColor.blackColor() - which will be UIColor.black() in Swift 3. ... which both do pretty much the same; they are used as convenience initialization for the specific type.

[swift-evolution] [Proposal] Enum subsets

This is loosely related to but not meant to 'compete' with the ad hoc enum proposal. ## Introduction This proposal adds/creates syntax to allow ad hoc creation of enums whose members are strict subsets of explicitly defined enums. Swift-evolution thread: [Discussion thread topic for that proposa

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

Sent from my iPad On Jun 3, 2016, at 7:08 AM, Brent Royal-Gordon wrote: >> This might be silly, but what if there were a struct with all of the >> relevant fields (not sure what the best name would be): >> >> struct MemoryLayout { >> let size: Int >> let alignment: Int >> let stride: Int >>

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

> This might be silly, but what if there were a struct with all of the relevant > fields (not sure what the best name would be): > > struct MemoryLayout { > let size: Int > let alignment: Int > let stride: Int > // etc > } > > Then you’d only maybe need two functions: > > memoryLayout(of:) a

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

On Jun 2, 2016, at 16:57, Sean Heber via swift-evolution mailto:swift-evolution@swift.org>> wrote: > This might be silly, but what if there were a struct with all of the relevant > fields (not sure what the best name would be): > > struct MemoryLayout { > let size: Int > let alignment: Int >