Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

On Mon, Jan 8, 2018 at 11:02 AM Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of SE-0194 "Derived Collection of Enum Cases" begins now and > runs through January 11, 2018. The proposal is available here: > > >

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

On Wed, Dec 20, 2017 at 4:19 PM Ted Kremenek via swift-evolution < swift-evolution@swift.org> wrote: > The review of "SE-0193 - Cross-module inlining and specialization" begins > now and runs through *January 5, 2018*. > > The proposal is available here: > > >

Re: [swift-evolution] Refining SE-0185: Should providing a custom == suppress the default hashValue?

Those are valid concerns for hashing algorithms in general, but there's no connection between that and a statement that an explicitly implemented hashValue should also require an explicitly implemented ==. Requiring that certainly doesn't make it less likely that people will run into the problem

Re: [swift-evolution] Refining SE-0185: Should providing a custom == suppress the default hashValue?

On Fri, Dec 15, 2017 at 6:41 PM Howard Lovatt wrote: > I think that is an advanced use, rather than a common use. I would prefer > that to be something you manually code. > But why? Why should implementing a subset of fields for hashValue require a developer to also

Re: [swift-evolution] Refining SE-0185: Should providing a custom == suppress the default hashValue?

On Fri, Dec 15, 2017 at 11:39 AM Howard Lovatt via swift-evolution < swift-evolution@swift.org> wrote: > +1 > I think the simple solution of if you provide either == or hashValue you > have to provide both is the best approach. Good catch of this bug. > -- Howard. > That would be a significant

Re: [swift-evolution] Refining SE-0185: Should providing a custom == suppress the default hashValue?

+1, that sounds like a reasonable way to handle that situation. This is another one of those pitfalls that could be mitigated with something like the "transient" attribute that was discussed in earlier discussion threads, but that's really about a slightly different problem statement—it would let

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Tue, Nov 28, 2017 at 11:23 AM Kelvin Ma via swift-evolution < swift-evolution@swift.org> wrote: > On Tue, Nov 28, 2017 at 12:59 PM, Joe Groff via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> >> > On Nov 28, 2017, at 10:52 AM, Vladimir.S wrote: >> > >> > On

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

alue expression > and omit an explicit argument (exactly as it does for unconstrained default > value expressions). > > These are very different things. The latter is not possible in Swift > today. It can only be emulated by providing an unnecessarily bloated > overload set. > So you s

Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

On Mon, Nov 27, 2017 at 5:34 PM Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of SE-0191 "Eliminate IndexDistance from Collection" begins now > and runs through December 3, 2017. The proposal is available here: > > >

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

mbiguity that could arise from allowing > multiple defaults with different (potentially overlapping) constraints. > That would be no different than the existing problem of multiple overloads with different (potentially overlapping) constraints, right? If what you're looking for is a way to have th

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

single type (or set of related types) known at compile time. Even if it's generic, it still must be expressed in terms of whatever constraints are present on that generic type—you can't use a disjunction of types, but instead have to have a common protocol that would provide some operation. > >

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

saying we should just go full-speed into an approach and hope that it "just works out". What I'm saying is, I think there's potential with that approach that I don't have enough knowledge in that area and I'm hoping someone with more knowledge will chime into the discussion. :) So to b

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

ntioned—we probably don't want people to be able to retroactively add overloads that would introduce a default where previously there was none. (This wouldn't be possible for global functions in different modules, but could be for non-private type members.) This might be something that Just Works Out™ depen

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

h method that needs them, you just define the functions once and refer to them everywhere. (Could you do the same with the annotation based method? Probably, if you allow arbitrary expressions within them. But that seems less obvious compared to this approach.) > > -- Howard. > > On 26 Nov

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

cessary). > > > -- Howard. > > On 26 Nov 2017, at 9:25 am, Tony Allevato via swift-evolution < > swift-evolution@swift.org> wrote: > > On Sat, Nov 25, 2017 at 1:16 PM Xiaodi Wu <xiaodi...@gmail.com> wrote: > >> On Sat, Nov 25, 2017 at 15:06 Matthew

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

On Mon, Nov 27, 2017 at 12:49 PM Matthew Johnson wrote: > On Nov 27, 2017, at 1:24 PM, Tony Allevato > wrote: > > > > On Mon, Nov 27, 2017 at 11:12 AM Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > >> On Nov 27, 2017,

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

m> >>> wrote: >>> >>>> On Sat, Nov 25, 2017 at 1:16 PM Xiaodi Wu <xiaodi...@gmail.com> wrote: >>>> >>>>> On Sat, Nov 25, 2017 at 15:06 Matthew Johnson <matt...@anandabits.com> >>>>> wrote: >>>>> >&

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

Sat, Nov 25, 2017 at 15:06 Matthew Johnson <matt...@anandabits.com> >>> wrote: >>> >>>> On Nov 25, 2017, at 1:28 PM, Tony Allevato via swift-evolution < >>>> swift-evolution@swift.org> wrote: >>>> >>>> On Fri, Nov 24, 2017 a

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

On Sat, Nov 25, 2017 at 1:16 PM Xiaodi Wu <xiaodi...@gmail.com> wrote: > On Sat, Nov 25, 2017 at 15:06 Matthew Johnson <matt...@anandabits.com> > wrote: > >> On Nov 25, 2017, at 1:28 PM, Tony Allevato via swift-evolution < >> swift-evolution@swift.org> wrote

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

On Fri, Nov 24, 2017 at 7:18 PM Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: It's kludgy, but we could have something like: > > ``` > @defaultArgument(configuration = (), where R.Configuration == Void) > @defaultArgument(actionHandler = { _ in }, where R.Action == Never) >

Re: [swift-evolution] [Pitch] Raw mode string literals

riate type based on the context they're used in. Handling different kinds of strings should leverage and extend that mechanism, not add new syntax. On Thu, Nov 23, 2017 at 2:43 PM Kelvin Ma <kelvin1...@gmail.com> wrote: > On Thu, Nov 23, 2017 at 3:47 PM, Tony Allevato via swift-evolution

Re: [swift-evolution] [Pitch] Raw mode string literals

On Thu, Nov 23, 2017 at 12:21 PM Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > On Thu, Nov 23, 2017 at 2:14 PM, John Holdsworth via swift-evolution < > swift-evolution@swift.org> wrote: > >> I’m beginning to wish I hadn’t tied this proposal so strongly to regular >>

Re: [swift-evolution] [Pitch] Make Optional, Array, and Dictionary conditionally Equatable

Agree with the sentiment above. Equatable conformance for collections is not just an obvious consequence of SE-0143 but one of the motivators—after all, Array is mentioned right in the intro. Let it be done without a full review cycle :) On Wed, Nov 22, 2017 at 12:04 PM Hooman Mehr via

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

Does that mean that once structural types can conform to protocols, would the core team want to remove Optional as a nominal type and just use “T?”? Or has that ship sailed because of source compatibility and you just don’t want to introduce any new nominals that shadow structurals? On Tue, Nov

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

ame as having variadic generics. > > If we had variadic generics, we could implement tuples conforming to > protocols, either by refactoring the compiler to allow conforming types to > be non-nominal, or by reworking things so that a tuple is a nominal type > with a single variadic gene

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

; be non-nominal, or by reworking things so that a tuple is a nominal type > with a single variadic generic parameter. > > Slava > > On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution < > swift-evolution@swift.org> wrote: > > This is something I've wanted to

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

This is something I've wanted to look at for a while. A few weeks ago I pushed out https://github.com/apple/swift/pull/12598 to extend the existing synthesis to handle structs/enums when a field/payload has a tuple of things that are Equatable/Hashable, and in that PR it was (rightly) observed, as

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

On Sat, Nov 11, 2017 at 1:53 PM Xiaodi Wu wrote: > On Sat, Nov 11, 2017 at 3:15 PM, Tony Allevato > wrote: > >> >> >> On Sat, Nov 11, 2017 at 10:28 AM Xiaodi Wu wrote: >> >>> On Sat, Nov 11, 2017 at 11:23 AM, Tony Allevato

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

On Sat, Nov 11, 2017 at 10:28 AM Xiaodi Wu wrote: > On Sat, Nov 11, 2017 at 11:23 AM, Tony Allevato > wrote: > >> >> >> On Fri, Nov 10, 2017 at 11:01 PM Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> Nit: if you want to

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

On Fri, Nov 10, 2017 at 11:01 PM Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > On Sat, Nov 11, 2017 at 12:15 AM, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org> wrote: > >> > Personally I like the flexibility provided by the associatedtype, but I >>

Re: [swift-evolution] Re-pitch: Deriving collections of enum cases

On Sun, Nov 5, 2017 at 11:54 PM Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote: > Over a year ago, we discussed adding a magic "allValues"/"allCases" static > property on enums with a compiler-derived implementation. The original > proposal > PR

Re: [swift-evolution] f suffix for float32 literals, h suffix for float16 literals

You can write this for the first thing that you want: let vertexData: [Float] = [1.0, 0.0, 0.5, 1.0] I don't know enough about 16-bit floats to comment on those. On Fri, Nov 3, 2017 at 11:26 AM nick ralabate via swift-evolution < swift-evolution@swift.org> wrote: > I think it would be

Re: [swift-evolution] Proposal: Allow operators to have parameters with default values

I like this idea as it's presented here, for the debugging/logging reasons that you stated. Should we tighten the shackles a little be to validate that *only* the special #file/#line/#function directives can be permitted for these extra parameters? I'm struggling to think of a case where we would

Re: [swift-evolution] Adding Result to the Standard Library

Proposing syntactic sugar for this at the same time would go a long way toward making me less reluctant to support it. As a type by itself, I don’t think it holds its weight in the standard library. The question that I’d want to see answered is, is it possible to make it so that these two

Re: [swift-evolution] Adding Result to the Standard Library

On Thu, Nov 2, 2017 at 12:41 PM Jon Shier wrote: > This isn’t an argument against Result, it’s an argument against all error > encapsulation in Swift at all. Which is fine for your personal project, but > frankly I don’t see it as a bad thing as a language capability. Like any

Re: [swift-evolution] Adding Result to the Standard Library

On Thu, Nov 2, 2017 at 12:21 PM Jon Shier wrote: > The Result type I’ve outlined includes the functions necessary to > translate between do try catch and Result. But I fundamentally disagree > with your characterization of Swift’s error handling. At most, Swift > strives to

Re: [swift-evolution] Adding Result to the Standard Library

On Thu, Nov 2, 2017 at 11:58 AM Jon Shier wrote: > You would continue to be free to discourage the usage of Result for > whatever you want. For the rest of us, Result isn’t intended to replace > throws or do/catch, but provide a way to accomplish things in a much more >

Re: [swift-evolution] Adding Result to the Standard Library

On Thu, Nov 2, 2017 at 11:32 AM Jon Shier wrote: > That’s been an argument against Result for 2 years now. The usefulness of > the type, even outside of whatever asynchronous language support the core > team comes up with, perhaps this year, perhaps next year, is still very >

Re: [swift-evolution] Adding Result to the Standard Library

Given that the Swift team is currently working on laying the groundwork for asynchronous APIs using an async/await model, which would presumably tie the throwing cases more naturally into the language than what is possible using completion-closures today, are we sure that this wouldn't duplicate

Re: [swift-evolution] Making capturing semantics of local functions explicit

Does the compiler treat a nested function differently from a closure in any meaningful way? (I suppose they might have symbols emitted in the symbol table, whereas a closure assigned to a local variable wouldn't?) It definitely seems odd that you can write two functionally equivalent pieces of

Re: [swift-evolution] Property Getter Return Statement

I think the important thing to consider is, what advantage would such a feature provide *other* than to reduce keystrokes? (I don't personally think that optimizing for keys pressed by itself should be a goal.) In the case of closures, single expression closures without "return" improve

Re: [swift-evolution] Property Getter Return Statement

For what it's worth, you can drop the "get" part for read-only computed properties and write: var session: AVCaptureSession { return layer.session } On Sat, Oct 7, 2017 at 7:07 AM James Valaitis via swift-evolution < swift-evolution@swift.org> wrote: > Is it widely agreed that it is

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

On Fri, Oct 6, 2017 at 9:29 PM Jose Cheyo Jimenez wrote: > On Oct 6, 2017, at 8:58 PM, Tony Allevato wrote: > > > > On Fri, Oct 6, 2017 at 8:45 PM Jose Cheyo Jimenez > wrote: > >> On Oct 6, 2017, at 8:01 PM, Tony Allevato

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

On Fri, Oct 6, 2017 at 8:45 PM Jose Cheyo Jimenez wrote: > On Oct 6, 2017, at 8:01 PM, Tony Allevato wrote: > >> >> At the time SE-0025 was accepted, "private extension" would have been > meaningless if it did not mean "fileprivate" because it

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

On Fri, Oct 6, 2017 at 7:07 PM Jose Cheyo Jimenez wrote: > On Oct 6, 2017, at 11:07 AM, Tony Allevato > wrote: > > On Fri, Oct 6, 2017 at 10:16 AM Jose Cheyo Jimenez via swift-evolution < > swift-evolution@swift.org> wrote: > >> On Oct 6, 2017, at

Re: [swift-evolution] Pitch: Restrict Cross-module Struct Initializers

Yes, this feels right. I was a little unsure/unclear about this at first, but the example with `let` and invariants convinced me, and now I can see how changing a stored property to a computed property later could cause problems in your scenario. So even though *technically* there is some subset

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

On Fri, Oct 6, 2017 at 10:16 AM Jose Cheyo Jimenez via swift-evolution < swift-evolution@swift.org> wrote: > On Oct 6, 2017, at 7:10 AM, Vladimir.S wrote: > > On 05.10.2017 20:52, Jose Cheyo Jimenez via swift-evolution wrote: > > On Oct 5, 2017, at 4:32 AM, David Hart

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

Yes, you're right about the history of "private extension"—I was forgetting some of the details of what transpired during those proposals. Thanks for the reminder. That being said, I would still argue that it would be a shame if we decided that the language should propagate a known inconsistency

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

Trust me, I'm the last person who wants to rehash access levels in Swift again. But that's not what's happening here, IMO, and fixing bugs is not just "a change for the sake of changing." The current behavior of "private extension" is *incorrect*, because it's entirely inconsistent with how

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

Thanks for hoisting this out into its own thread, Jordan. I was hesitant to elaborate more on another access level thread :) I think the change should absolutely be made. Even though the "private" keyword occurs at the file level, the description of the feature in the Swift documentation simply

Re: [swift-evolution] Idea: Public Access Modifier Respected in Type Definition

I don't want this to come across as though I'm trying to shut down discussion (because it's not my place to do so), but a significant amount of time was spent during the Swift 4 design phases debating how access levels should work, decisions were made, and I think many of us would like to move on

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

On Wed, Sep 27, 2017 at 10:36 AM Ben Cohen via swift-evolution < swift-evolution@swift.org> wrote: > > > On Sep 25, 2017, at 2:12 AM, Alwyn Concessao via swift-evolution < > swift-evolution@swift.org> wrote: > > mutating func removeElementInSubrange(_ elementToBeRemoved:Element,in > range:Range){

Re: [swift-evolution] Retroactive protocol inheritance

This is mentioned in the Generics Manifesto as "Conditional Conformances via Protocol Extensions": < https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-via-protocol-extensions > While it would be a very powerful and useful feature, it's apparently also

Re: [swift-evolution] [Review] SE-0176: Remove ownership keyword support in protocols

On Wed, Sep 20, 2017 at 1:11 PM Ted Kremenek via swift-evolution < swift-evolution@swift.org> wrote: > The review of “SE-0186: Remove ownership keyword support in protocols” > begins now and runs through September 27. > > The proposal is available here: > > >

Re: [swift-evolution] Different types for getter and setter

There have been a couple times where I've wanted something like this: 1) A nil-resettable property without having to resort to making it an IUO. It would be nice to have the setter able to take a T? but the getter return T, and the setter would provide a default value in the event that it

Re: [swift-evolution] [Question] Absolute paths in executable .swiftmodule files

Thanks for bringing this up, Pepper! We have many of the same issues with our Swift support in Bazel ; since .swiftmodule files aren't hermetic, we can't reliably cache them. The proliferation of import paths in the modules is another major issue—as part of

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

On Wed, Sep 13, 2017 at 11:47 AM Vladimir.S wrote: > On 13.09.2017 20:48, Tony Allevato wrote: > > On Wed, Sep 13, 2017 at 10:21 AM Vladimir.S via swift-evolution > > > wrote: > > > > On 13.09.2017 19:08, Ondrej

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

On Wed, Sep 13, 2017 at 10:21 AM Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > On 13.09.2017 19:08, Ondrej Barina via swift-evolution wrote: > > Maybe something like this as middle ground. > > > > protocol Equatable { > > @syntetic static func ==(_ lhs: Self, _ rhs:

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

decoders. It's true that the compiler uses that enum to decide what to synthesize, but the compiler also uses *the values themselves* in that synthesized implementation. The hypothetical Equatable/HashableKeys enum would not contain any data. It would not be used at runtime. It would not be passed arou

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

here that a hypothetical EquatableKey/HashableKey would be the same thing as CodingKey. CodingKey embeds other semantic information, like the string or integer key to use when encoding/decoding a value in a container. The cases of a CodingKey enum are also actual values that are passe

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

ve been one, but it doesn't reduce any of the burden of having to provide the appropriate manual implementation. But all that stuff about custom attributes and metaprogramming introspection is a big topic of it's own that isn't going to be solved in Swift 5, so this is a bit of a digression. :

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

On Tue, Sep 12, 2017 at 8:10 AM Gwendal Roué wrote: > >> There is this sample code by Thorsten Seitz with a cached property > which is quite simple and clear : > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170911/039684.html > >> > >> This is the

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

On Tue, Sep 12, 2017 at 3:32 AM Vladimir.S wrote: > On 12.09.2017 0:35, Tony Allevato wrote: > > > > > > On Mon, Sep 11, 2017 at 2:05 PM Vladimir.S via swift-evolution > > > wrote: > > > > On 11.09.2017 21:55,

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

On Mon, Sep 11, 2017 at 10:05 PM Gwendal Roué wrote: > >> This doesn't align with how Swift views the role of protocols, though. >> One of the criteria that the core team has said they look for in a protocol >> is "what generic algorithms would be written using this

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

On Mon, Sep 11, 2017 at 2:43 PM Gwendal Roué via swift-evolution < swift-evolution@swift.org> wrote: > Doesn't it escalate pretty quickly into complex and ad-hoc language > constructs? > > Like everybody I like code synthesis. Like some, I'm worried that implicit > synthesis would hide a few bugs

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

On Mon, Sep 11, 2017 at 2:05 PM Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > On 11.09.2017 21:55, Thorsten Seitz via swift-evolution wrote: > > I think I do understand Haravikk's argument (actually it seems quite > straightforward > > to me). > > > > An example should be:

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

On Mon, Sep 11, 2017 at 11:56 AM Thorsten Seitz via swift-evolution < swift-evolution@swift.org> wrote: > I think I do understand Haravikk's argument (actually it seems quite > straightforward to me). > > An example should be: > > struct Foo : Equatable { > var x: Int > var cachedLabel:

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

>>> On Fri, Sep 8, 2017 at 8:35 AM Matthew Johnson <matt...@anandabits.com> >>> wrote: >>> >>>> On Sep 8, 2017, at 9:53 AM, Tony Allevato via swift-evolution < >>>> swift-evolution@swift.org> wrote: >>>> >>>> Than

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

On Sat, Sep 9, 2017 at 11:36 AM Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > > Sent from my iPad > > On Sep 9, 2017, at 11:42 AM, gs. wrote: > > How does fragility play into this? Does this only work for fragile > (closed) and

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

t;> On Sep 8, 2017, at 9:53 AM, Tony Allevato via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> Thanks for bringing this up, Logan! It's something I've been thinking >> about a lot lately after a conversation with some colleagues outside of >> this

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

On Fri, Sep 8, 2017 at 8:35 AM Matthew Johnson <matt...@anandabits.com> wrote: > On Sep 8, 2017, at 9:53 AM, Tony Allevato via swift-evolution < > swift-evolution@swift.org> wrote: > > Thanks for bringing this up, Logan! It's something I've been thinking > about a lot

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

Thanks for bringing this up, Logan! It's something I've been thinking about a lot lately after a conversation with some colleagues outside of this community. Some of my thoughts: AFAIK, there are two major use cases here: (1) you need the whole collection of cases, like in your example, and (2)

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

On Thu, Sep 7, 2017 at 10:39 AM Gwendal Roué wrote: > Le 7 sept. 2017 à 14:45, Tony Allevato a écrit : > > Right, let's make sure we're talking about the right thing here. Gwendal, > your issue isn't with synthesis in the form of Codable or the

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

Right, let's make sure we're talking about the right thing here. Gwendal, your issue isn't with synthesis in the form of Codable or the new additions to Equatable/Hashable which are opt-in-by-conformance, it's with the specific case of raw value enums or enums without associated values where the

Re: [swift-evolution] [Pitch] Adding accessibility specifiers to @available

Whew! Thanks for the heads-up before my prototype hits merge-conflict madness. :) On Tue, Aug 22, 2017 at 1:16 PM Ben Rimmington wrote: > > On 22 Aug 2017, at 17:08, Tony Allevato wrote: > > > > A few months ago (before Swift 5 chatter started), I pitched an idea to >

[swift-evolution] [Pitch] Adding accessibility specifiers to @available

Hi all, A few months ago (before Swift 5 chatter started), I pitched an idea to improve the use of @availability in third-party code by eliminating deprecation warnings in same-file references . We had some good

Re: [swift-evolution] Constrained Protocol Aliases

On Mon, Aug 21, 2017 at 5:51 AM David Hart via swift-evolution < swift-evolution@swift.org> wrote: > On 21 Aug 2017, at 13:36, Adrian Zubarev > wrote: > > It’s part of Generalized Existentials, but does not make it complete. I > think it would be worth adding

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

hat array, map transposing values or > indices into buttons is already covered. > > On Thu, Aug 17, 2017 at 5:03 PM, Tony Allevato via swift-evolution < > swift-evolution@swift.org> wrote: > >> Couldn't this be rewritten more simply today as: >> >> Array

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

Couldn't this be rewritten more simply today as: Array((0..<3).map { index in MyView(forIndex: index) }) And the version that doesn't need the index could be written: Array((0..<3).map { _ in UIView() }) The AnyIterator approach posted above is also nice—I wouldn't have thought of that

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

s > if, upon deserializing, one stumbles upon a hash collision which did not > occur with the original hashes. And I suppose the answer to that is...yes? > > > On Wed, Aug 16, 2017 at 6:16 PM, Tony Allevato via swift-evolution < > swift-evolution@swift.org> wrote: > >> Fro

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

>From what I can tell the hash values of elements in a Set don't come into play during encoding/decoding: they're merely serialized as the sequence of their elements. https://github.com/apple/swift/blob/2e5817ebe15b8c2fc2459e08c1d462053cbb9a99/stdlib/public/core/Codable.swift#L4073-L4097 On Wed,

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

Do you mean something like this, then? ``` struct Foo: Equatable { let x: Int } func test(_ lhs: T, _ rhs: T) -> Bool { return lhs == rhs } extension Foo { static func == (lhs: Foo, rhs: Foo) -> Bool { return lhs.x % 2 == rhs.x % 2 } } print(test(Foo(x: 5), Foo(x: 7))) // true ```

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

On Thu, Aug 10, 2017 at 3:40 AM Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > > On 10 Aug 2017, at 10:32, Martin Waitz wrote: > > Hi Haravikk, > > Am 2017-08-10 11:07, schrieb Haravikk via swift-evolution: > > I don't feel that conforming to >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

On Wed, Aug 9, 2017 at 4:59 PM Michael Ilseman via swift-evolution < swift-evolution@swift.org> wrote: > > On Aug 9, 2017, at 4:09 PM, Chris Lattner wrote: > > Hello Swift community, > > The review of SE-0185 - "Synthesizing Equatable and Hashable conformance" > begins now

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

On Wed, Aug 9, 2017 at 4:36 PM Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > On Wed, Aug 9, 2017 at 6:08 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > >> Hello Swift community, >> >> The review of SE-0185 - "Synthesizing Equatable and Hashable

Re: [swift-evolution] Enums and Source Compatibility

On Wed, Aug 9, 2017 at 9:40 AM David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > (Now with more mailing lists in the "to" field!) > On Aug 8, 2017, at 3:27 PM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote: > > Hi, everyone. Now that Swift 5 is

Re: [swift-evolution] [Proposal] Synthesizing Equatable/Hashable conformance for enums and structs

ice? > Either or both members can be replaced with manual implementations—of course it's up to the user at that point to keep those implementations behaviorally consistent. Doing so does not change the behavior described above regarding the protocol conformance list. > Thanks, > > Ne

[swift-evolution] [Proposal] Synthesizing Equatable/Hashable conformance for enums and structs

Now that Swift 5 is taking proposals, I'm dusting off my proposal to synthesize Equatable/Hashable conformance for enums and structs. I had implemented this a few months ago hoping to squeeze it in by the Swift 4 deadline, but unfortunately the timeline was too tight. The pull request for the

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

ecause the second ? signals an optional but > not a non-optional or an inplicit unwrapped operator. In that case I > personally thing ?! would make more sense. Unwrap or (non-optional | IUO | > trap/die) > > -- > Adrian Zubarev > Sent with Airmail > > Am 28. Juni 2017 um 18:13:

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

It's hard for me to articulate, but "foo !! message" feels a little too much like a Perl-ism for my taste. Objectively that's not a great criticism on its own, but I just don't like the "smell" of an operator that takes a value on one side and a string for error reporting purposes on the other. It

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

The idea behind `?? () -> Never` is that it leaves no other choice in the nil case but to do something that dies, and that something is typically a function call like fatalError() that documents well enough the dying so !! would be unnecessary. And since it was pointed out above that this can be

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

I agree with Jaden and Xiaodi above—making Never a proper bottom type and using ?? would accomplish the same thing, and it's more general because it doesn't imply fatalError. IMO, I don't think we should be making it *easier* to hide traps in our code. I don't think having to write a full

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 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

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

Re: [swift-evolution] In-line scope designators

On Tue, Jun 20, 2017 at 8:57 AM Ted F.A. van Gaalen wrote: > Hi Tony > I don’t think so, then I would have to split my class up into extensions, > not really workable I’d say. > Why not? What makes this workable: struct MyType { internal: var var var

Re: [swift-evolution] In-line scope designators

You can already effectively have these "regions" using extensions, with the exception of stored properties since they can't be placed there. struct MyType { ... } public extension MyType { ... } private extension MyType { ... } Once stored properties are allowed in extensions (IIRC supporting

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

+1 to this. My ideal imagining of this behavior is to: 1) Define a protocol containing the precise operations you want to support via forwarding. 2) Internally/fileprivately extend the original type to conform to this protocol. 3) In your new type, tell it to forward protocol members for a

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

Makes sense. I guess from an implementation point of view, the compiler only needs to be able to see the signatures of the members to synthesize the calls to them. My thinking was that conforming the original type would remove the need for the compiler to verify separately that the members exist

Re: [swift-evolution] Int indexing into UTF16View

It is an extremely rare case for a developer to know a priori what literal numeric indices should be used when indexing into a string, because it only applies when strings fall into a very specific format and encoding. It's been discussed before during String-related proposals but AFAIK the core

  1   2   3   >