Re: [swift-evolution] No disjunctions in type constraints: why?

If you replace “conjunction” by “O(n) search with early-exit on failure” and “disjunction” by just “O(n) search”, you’ll see why this can lead to computationally painful systems of constraints. Each disjunctive constraint may further contain or create disjunctions ad nauseum, each time

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

~Robert Widmann 2017/12/31 11:02、Karl Wagner via swift-evolution のメール: > > >> On 31. Dec 2017, at 00:12, Jacob Bandes-Storch via swift-evolution >> wrote: >> >> Sorry for the delay. I've just updated the proposal text to incorporate

Re: [swift-evolution] [Idea] [Pitch] Add `match` statement as `switch`-like syntax alternative to `if case` pattern matching

In regards to the problem in the root (using if-cases to do membership tests on option sets), the code given there involving thinking of the OptionSet as a sequence and iterating over it makes this far less likely to happen. I think this is a pattern that doesn't need syntax, it needs stdlib

Re: [swift-evolution] [Idea] [Pitch] Add `match` statement as `switch`-like syntax alternative to `if case` pattern matching

> On Nov 18, 2017, at 4:42 AM, Peter Kamb wrote: > > Thanks for the review. > > Motivation is essentially to provide a low-friction way to write `if case / > if case / if case` statements that are all matching on the same expression, > much in the same way that `switch`

Re: [swift-evolution] [Idea] [Pitch] Add `match` statement as `switch`-like syntax alternative to `if case` pattern matching

Having spent a lot of time with ‘switch’, I don’t understand any of the motivations or corresponding justifications for this idea. Comments inline: ~Robert Widmann 2017/11/17 15:06、Peter Kamb via swift-evolution のメール: > ## Title > > Add `match` statement as

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

~Robert Widmann 2017/11/14 22:02、Matthew Johnson via swift-evolution のメール: > > > Sent from my iPhone > >> On Nov 14, 2017, at 6:56 PM, Howard Lovatt via swift-evolution >> wrote: >> >> Having read all the arguments for what to add

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

A quick thing I noticed on a first read (sort of tangential to the rest of the discussion) is that it would be a good idea to land warnings for potential reference cycles sooner rather than later. I have an (un-rebased) branch that lays out what parts of Sema needs to be touched to make this

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

> On Nov 6, 2017, at 2:54 AM, Jacob Bandes-Storch via swift-dev > 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] [SE-0155][Discuss] The role of labels in enum case patterns

sion and review of >>>> this proposal. >>>> >>>>> >>>>> On Sun, Sep 3, 2017 at 4:35 PM, Xiaodi Wu via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> T

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

standpoint, a requirement for labels in all cases would be >>> much more source-breaking, whereas the proposal as it stands would allow >>> currently omitted labels to continue being valid. Moreover, and I think >>> this is a worthy consideration, one argument for permitting

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

ing valid. Moreover, and I think this >> is a worthy consideration, one argument for permitting the omission of >> labels during pattern matching is to encourage API designers to use labels >> to clarify initialization without forcing its use by API consumers during >> ever

[swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

Hello Swift Evolution, I took up the cause of implementing SE-0155 , and am most of the way through the larger points of the proposal. One thing struck me when I got to the part about

Re: [swift-evolution] [discussion] Class stored properties?

This is a singleton, it just happens to be in class scope. ~Robert Widmann > On Aug 9, 2017, at 3:55 AM, Mathew Huusko V via swift-evolution > wrote: > > Curious if class stored properties have ever been discussed (doesn't seem > so..)? > > Also, assuming no, and

Re: [swift-evolution] [Idea] Creating an enums as a sum of multiple other enums

Not a response to the core of this, but to the motivating example: Sectioned (or multi-sorted in other cases) ASTs can also be represented by a singly-sorted AST and views over top enum UnaryOperatorView { case not } enum BinaryOperatorView { case and case or } enum BooleanLiteralView {

Re: [swift-evolution] [Pitch] Update to Alternative Types (i.e. strong typedef) Proposal

> On Jul 31, 2017, at 4:08 PM, Daryle Walker wrote: > >> On Jul 31, 2017, at 1:45 PM, Robert Widmann > > wrote: >> >> As I was saying, I agree with the overall usefulness of newtype-style >> declarations, but I don’t

Re: [swift-evolution] [Pitch][Bug?] Test for Anti-Conformance During Generics

> On Jul 31, 2017, at 10:34 AM, Daryle Walker via swift-evolution > wrote: > > >> On Jul 31, 2017, at 1:33 AM, Daryle Walker > > wrote: >> >>> On Jul 31, 2017, at 1:19 AM, Xiaodi Wu >>

Re: [swift-evolution] [Pitch] Update to Alternative Types (i.e. strong typedef) Proposal

(Excuse me, my last reply was sent prematurely) As I was saying, I agree with the overall usefulness of newtype-style declarations, but I don’t understand why we need so much syntax for what should just be a pattern in Swift. Specifically, the idea of automatic delegation of an interface is

Re: [swift-evolution] [Pitch] Update to Alternative Types (i.e. strong typedef) Proposal

I agree with the overall usefulness of newtype-style ( > On Jul 29, 2017, at 4:01 PM, Daryle Walker via swift-evolution > wrote: > > Proposal at >

Re: [swift-evolution] Recent change makes Swift 4 less safe.

I don’t agree with your assertions that this makes Swift “less safe” - if anything the bug that this fixed was anything but. When performing a pattern match, we expect the pattern to match the “shape” of the declaration itself. If ‘()’ was not part of that declaration, then you have no reason

Re: [swift-evolution] [Pitch] Array full proposal

> On Jul 12, 2017, at 9:09 PM, Daryle Walker wrote: > > >> On Jul 12, 2017, at 4:05 PM, Robert Widmann wrote: >> >> I think this proposal is trying to do too much at once. Correct me if I’m >> wrong, but you’re proposing >> >> 1) New sugar for

Re: [swift-evolution] Better handling of enum cases with associated values

I like the spirit of this idea because it matches features found in other languages that have prominent pattern matching (ML, Haskell, etc.). But I’m concerned about the overloading of existing syntax for this case. Plus, if you find yourself destructuring large enum cases like this, have you

Re: [swift-evolution] [Pitch] Array full proposal

I think this proposal is trying to do too much at once. Correct me if I’m wrong, but you’re proposing 1) New sugar for fixed-length arrays without a corresponding stdlib declaration 2) Arity and type inference for literals 3) Default initialization semantics for arrays including a DI exception

Re: [swift-evolution] SE-0168: Multi-Line String Literals

A quick question since we’ve already accepted this proposal and have an implementation in-tree: do you expect this breaking change to be accepted for Swift 4, or do you expect this change to break everybody once they’ve already migrated to the triple-quoted string form in a future release?

Re: [swift-evolution] [Pitch] Swift run Command

+1. A very useful feature to have, indeed. ~Robert Widmann > On May 15, 2017, at 1:47 AM, David Hart via swift-evolution > wrote: > > Hello evolution (and build-dev), > > I’d like to pitch a QOL proposal to improve the development of command-line > Swift Packages

Re: [swift-evolution] [Pitch] Never as a bottom type

> > But it has its limits, most notably, it cannot be used as an expression > > let dunno: Int = fatalError("what should I put here?") // cannot convert > value of type 'Never' > Though our type lattice doesn’t necessarily have a bottom in the way you’re looking for, you can use

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

~Robert Widmann 2017/05/05 14:07、John McCall <rjmcc...@apple.com> のメッセージ: >> On May 4, 2017, at 10:52 PM, Robert Widmann via swift-evolution >> <swift-evolution@swift.org> wrote: >> - Parse: Has to account for the inclusion of tuple shuffles whenever it >

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

>> >>>> To be clear, are you proposing the prohibition of *adding or removing* >>>> labels as well? A previous discussion on tuple shuffling on this list saw >>>> consensus that assigning a value of type (label1: T, label2: U) to a >>>> variable of type (T, U)

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

To clarify for the root. Disregard the “Detailed Design” section attached to this email. The proposal on Github no longer seeks to remove labeled tuple patterns from the language. > On May 4, 2017, at 10:14 PM, Robert Widmann wrote: > > Hi all, > > So sorry that

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

>> >>>> To be clear, are you proposing the prohibition of *adding or removing* >>>> labels as well? A previous discussion on tuple shuffling on this list saw >>>> consensus that assigning a value of type (label1: T, label2: U) to a >>>> variable of type (T, U)

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

ell? A previous discussion on tuple shuffling on this list >>>>>> saw consensus that assigning a value of type (label1: T, label2: U) to a >>>>>> variable of type (T, U) and vice versa should absolutely be supported, >>>>>> whether

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

>>> (partialValue: Int, overflow: ArithmeticOverflow). >>>> >>>> Either one of these scenarios is commonly used, and it is astonishing to >>>> me that they would be eliminated. >>>> >>>>> On Thu, May 4, 2017 at 23:28 Robert Widmann <devteam.cod...@gm

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

t; > (x, y) = (y, x) // swap without a temporary value > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 5. Mai 2017 um 04:15:12, Robert Widmann via swift-evolution > (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

estructuring entirely, which I would >> think to be very much unacceptable. Example: >> >> ``` >> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42) >> ``` >> >> This involves no shuffling and should absolutely remain allowed. &

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

> This involves no shuffling and should absolutely remain allowed. > > >> On Thu, May 4, 2017 at 21:15 Robert Widmann via swift-evolution >> <swift-evolution@swift.org> wrote: >> Hi all, >> >> So sorry that this proposal comes so late in the game, but

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

- Parse: Has to account for the inclusion of tuple shuffles whenever it parses patterns (see the switch-statement example in the proposal) - Sema: Has to perform argument matching by computing these tuple shuffle mappings thereby complicating the solver and the parts of solution application.

[swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

Hi all, So sorry that this proposal comes so late in the game, but I feel it’s too important not to bring it to the attention of the community now. Attached is a proposal to deprecate a language feature many of you will probably have never had the chance to use: Tuple Shuffles. I’ve attached

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

> On Apr 30, 2017, at 1:43 PM, Gor Gyolchanyan wrote: > > It doesn’t have to be a massive source-break, since this pitch is supposed to > be a strict superset of what Optional and throwing is currently. > The only thing that I can think of at this moment that would break

Re: [swift-evolution] switch must be exhaustive, consider adding a default clause

What Joe is referring to is the kind of refinement-style rules that would be necessary to teach the type checker about how to that kind of analysis. Right now, all our switch analysis, and even this example, are just DI and control-flow checks. > On Apr 11, 2017, at 2:24 PM, Drew Crawford via

Re: [swift-evolution] (Pitch) Conformance Regions

Any proposal that seeks to add private conformances needs to answer to the dynamic side of Swift, most importantly: What does this return: let f = Foo() f is Bar If the answer is “it depends”, it needs to be explicitly stated where and how. > On Mar 30, 2017, at 1:07 PM, Ross O'Brien via

Re: [swift-evolution] [Draft] Package Manager Custom Targets Layout

A huge +1 for this proposal (and I’m definitely saying that partially because it folds in the test targets proposal). Having a flexible layout will make packages that need to support additional structure for things like alternative package managers or more exotic dependency trees a reality.

Re: [swift-evolution] [Proposal] [Discussion] Explicit Toll-Free Conversions

Correct. This section is referring more to the NS-side of things. > On Mar 23, 2017, at 1:38 AM, Slava Pestov <spes...@apple.com> wrote: > > >> On Mar 22, 2017, at 10:35 PM, Robert Widmann via swift-evolution >> <swift-evolution@swift.org <mailto:

[swift-evolution] [Proposal] [Discussion] Explicit Toll-Free Conversions

Good evening all, Attached is the proposal text that came out of a short discussion on Twitter about squashing one more case of implicit conversions in the language. This proposal seeks to remove the implicit nature of toll-free

Re: [swift-evolution] Property Selectors

Lenses ! My only concern is that arbitrary effects can be attached to setters and getters, which can lead to surprising results when using the property reference. As a language feature, I’d be interested to see where discussion around this will lead.

Re: [swift-evolution] List all values of a simple enum and extension constraint to enum types

This feature keeps being brought up. SR-3050 and rdar://problem/28952398 are tracking it, as well as this Evolution proposal by Jacob . The implementation has been discussed multiple times on social

Re: [swift-evolution] Infer types of default function parameters

You may be missing/misspelling the typealias declaration. This has been in Policy.swift for a while now, and I can reproduce this as far back as 2.2 in the Bluemix sandbox. ~Robert Widmann > On Mar 11, 2017, at 7:41 PM, Jaden Geller via swift-evolution > wrote: >

Re: [swift-evolution] [Draft] Really Simple Submodules

> On Mar 6, 2017, at 10:22 AM, Michel Fortin wrote: > > I believe `submodule` in my proposal introduces a segmented-scope-like thing, > akin to how the various files included in a module are combined as one > collection of declarations. And you have the ability to

Re: [swift-evolution] [Draft] Really Simple Submodules

battle-tested. ~Robert Widmann 2017/03/06 8:31、Matthew Johnson <matt...@anandabits.com <mailto:matt...@anandabits.com>> のメッセージ: > > > Sent from my iPad > > On Mar 6, 2017, at 1:39 AM, Robert Widmann via swift-evolution > <swift-evolution@swift.org <mail

Re: [swift-evolution] A Modest (multi-module) Proposal

What seems most suspect to me is the relation of a Swift module to a build target. Do you mean we literally mate the concepts and provide IDE support, or is that more of a conceptual point? I think the package manager's eventual goal of supporting multi-product packages covers most of what

Re: [swift-evolution] [Draft] Really Simple Submodules

If this were a problem that could be fixed by tooling, you'd be submitting this proposal against the package manager. It's important to note I'm approaching this problem from the principles that underpin modular programming practices in other languages, it is not merely "philosophical". A

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

A lot of “Swift Style” is “LLVM Style” enforced in little corners of the language (I, too, like to keep my cases indented a bit further). There are formatting tools available to make your Swift look C#-ish if you want :) > On Mar 5, 2017, at 7:21 AM, Joanna Carter via swift-evolution >

Re: [swift-evolution] [Draft] Really Simple Submodules

This proposal strikes me not as a submodules proposal, but as a sneaky way to add 'friend' to Swift. It is conceptually simpler because it doesn't address modularity at all! ~Robert Widmann 2017/03/05 17:16、Michel Fortin via swift-evolution のメッセージ: > Sorry for

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

~Robert Widmann 2017/03/03 16:10、Matthew Johnson のメッセージ: > >> On Mar 2, 2017, at 10:52 PM, T.J. Usiyan wrote: >> >> Submodules will, I hope, afford us the ability to share meaningfully >> arranged API. In an ideal scenario, I could have a

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 22, 2017, at 12:41 AM, Matthew Johnson wrote: > > > > Sent from my iPad > > On Feb 21, 2017, at 11:09 PM, Robert Widmann > wrote: > >> >>> On Feb 21, 2017, at 11:59 PM, Matthew Johnson

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 11:59 PM, Matthew Johnson wrote: > > >> On Feb 21, 2017, at 10:41 PM, Robert Widmann > > wrote: >> >> By API boundaries I mean both the one internal to MyModule.Foo and the one >>

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

>> <mailto:matt...@anandabits.com>> wrote: >> >>> >>> On Feb 21, 2017, at 9:28 PM, Robert Widmann via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>>> >>>

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

By API boundaries I mean both the one internal to MyModule.Foo and the one defined by MyModule. Here “the API boundary” is explicitly about the submodule MyModule.Foo, whose internal state may have been “unsealed” in the top level by the extension, but has not been re-exported. ~Robert

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

st, but I think it’s undesirable and we’re > trying to design something for the future here. > >> >> >>> On Feb 21, 2017, at 11:21 PM, Matthew Johnson <matt...@anandabits.com >>> <mailto:matt...@anandabits.com>> wrote: >>> >>

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

This level of access, the “private to this submodule except to the select set of interfaces I want to see it” level, is the equivalent of friend classes in C++. I don’t consider leaving this out to be a hole, nor is it an "encapsulation-related problem” because at no point can you break the

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

a top-level import. We decided not to change this behavior to maintain source compatibility. > On Feb 21, 2017, at 11:21 PM, Matthew Johnson <matt...@anandabits.com> wrote: > >> >> On Feb 20, 2017, at 7:56 PM, Robert Widmann via swift-evolution >> <swift-evolu

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Whoops, move bar() out of the utility and you get the actual answer here, because you want to be able to see this in foo()! > On Feb 21, 2017, at 10:54 PM, Robert Widmann wrote: > > This case is unserved because it is anti-modular and a nightmare to maintain. > The

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

This case is unserved because it is anti-modular and a nightmare to maintain. The actual way to structure this is to factor bar() and baz() into their own utility submodule, or even deeper if necessary, that has as a parent the primary module that wishes to consume them both but not re-export

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 10:36 PM, Matthew Johnson <matt...@anandabits.com> wrote: > >> >> On Feb 21, 2017, at 9:28 PM, Robert Widmann via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Correct. Because, in dividing the submodule across an extension, you have placed what should be a private API into a differently-scoped location. > On Feb 21, 2017, at 10:34 PM, Brent Royal-Gordon > wrote: > >> On Feb 21, 2017, at 7:14 PM, Robert Widmann

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

ign support the use case below? I > don't think it does. Are you replying that supporting the use case below is > not a goal of your proposal? If so, please just say so. > > >> On Feb 21, 2017, at 10:26 PM, Xiaodi Wu <xiaodi...@gmail.com >> <mailto:xiaodi...@gmail

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Tue, Feb 21, 2017 at 9:08 PM, Robert Widmann via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > Sorry, been replying to multiple sub-threads today. > > > For ba

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

@gmail.com >> <mailto:xiaodi...@gmail.com>> wrote: >> >> On Tue, Feb 21, 2017 at 8:22 PM, Robert Widmann <devteam.cod...@gmail.com >> <mailto:devteam.cod...@gmail.com>>wrote: >> >>> On Feb 21, 2017, at 9:13 PM, Xiaodi Wu <xiaodi...@gmail.c

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Fileprivate and private are not changing at all. Their meaning now extends from “private to this file” and “private to this declaration” respectively to those meanings plus “unexportable across any module boundary”. One implication of this is it is now possible to create module-scoped private

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Sorry, been replying to multiple sub-threads today. For bar(), because you wish to be able to 1) Not export it across the outermost module boundary 2) But still use it internally Internal access is required. Any higher and you would export (violating 1), any lower and you wouldn’t be able

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

What is implied by the definition of `internal` in the proposal (which should, as this thread has shown, be stated explicitly) is that by “export” we mean “export to clients” across the outermost module-boundary. Any API that is not public is, by definition, not able to cross this outermost

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 9:49 PM, Brent Royal-Gordon > wrote: > >> On Feb 21, 2017, at 6:43 PM, Robert Widmann wrote: >> >> That is not what this proposal requires. A public API is ripe for >> re(export), but if the parent wishes to

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

017, at 9:19 PM, Xiaodi Wu <xiaodi...@gmail.com >> <mailto:xiaodi...@gmail.com>> wrote: >> >> On Tue, Feb 21, 2017 at 8:15 PM, Robert Widmann via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>>

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 9:38 PM, Brent Royal-Gordon > wrote: > >> On Feb 21, 2017, at 6:09 PM, Robert Widmann wrote: >> >>> If I'm reading this correctly, you're proposing that the `internal` APIs in >>> a submodule should *not* be accessible

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

@gmail.com >> <mailto:xiaodi...@gmail.com>> wrote: >> >> On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Feb 21, 2017, at 7:36 PM, Nevin B

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 9:13 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> On Feb 21, 2017, at 7:36 PM, Nevi

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 7:46 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 21, 2017, at 1:28 AM, Daniel Duan via swift-evolution >> wrote: >> >> It has been my hope that a lightweight module system will remove the need

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 8:00 AM, Brent Royal-Gordon <br...@architechies.com> > wrote: > >> On Feb 20, 2017, at 5:56 PM, Robert Widmann via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> The semantics of some existing access control mo

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > To my mind, any submodule system for Swift should be designed to relieve the > pressure for long files, and make it easy to group tightly related files into > a single unit with

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

; >>> wrote: >>> >>> >>>> On Feb 21, 2017, at 2:01 AM, Jonathan Hull <jh...@gbis.com> wrote: >>>> >>>> >>>> On Feb 20, 2017, at 10:46 PM, Robert Widmann via swift-evolution >>>> <swift-evolution@swi

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Sounds distressingly anti-modular! Really, these kinds of hypotheticals can be addressed when the need arises. For now it's a hypothetical fear about a hypothetical issue that isn't expressible and highly discouraged by this system - why produce an inverted dependency when you could simply

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 2:01 AM, Jonathan Hull <jh...@gbis.com> wrote: > > >> On Feb 20, 2017, at 10:46 PM, Robert Widmann via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> More generally, w

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

gt;>>> >>>> // This defines “Foo.Bar.Baz”, but would you know that if it appeared >>>> below the fold? >>>> module Baz {} >>>> //} >>>> >>>> If anything, this can be added later if evolution converges on it. >&

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 1:46 AM, Jonathan Hull wrote: > > >> On Feb 20, 2017, at 6:44 PM, Robert Widmann > > wrote: >> >>> >>> >>> I would honestly love to see something which just maps modules to >>> folders/groups

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

around and bite us. ~ Robert Widmann > > Sent from my iPad > > On Feb 20, 2017, at 7:56 PM, Robert Widmann via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> Good Evening All, >> >> Jaden Geller an

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

nothing about this scheme that prevents you from organizing your >> code this way. However, modulo that particular method of organization, you >> don’t really gain much as a user of the language by imposing this >> restriction. >> >>> I haven’t thought ab

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

too much yet, so I could easily be missing > something obvious... > > Thanks, > Jon > > >> On Feb 20, 2017, at 5:56 PM, Robert Widmann via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Good Evening Al

[swift-evolution] [Proposal][Discussion] Modular Swift

Good Evening All, Jaden Geller and I have been considering a (sub)module system for Swift that would complement the existing language but also provide sorely needed modularity. A draft of the proposal is attached to this email, but it can also be read as a gist

Re: [swift-evolution] [Pitch] Let's talk about submodules

You’ll be delighted to know, then, that I’ve been thinking about this for a few weeks now and have a draft proposal that will be submitted for discussion shortly. I believe this can be an additive feature and still preserve all the goodness you would expect of a real module system. ~Robert

Re: [swift-evolution] [Fake-Proposal] Remove enums with associated objects

A lot of problems look algebra-like. Best to have sums and products at your disposal. Cheekily, ~Robert Widmann 2017/02/20 15:07、Tino Heth via swift-evolution のメッセージ: > Obviously, this won't become an accepted proposal - neither the time nor the > author would

Re: [swift-evolution] A compiler option to warn if a closure captures a strong reference to a class instance?

It's important to note that strong captures by default are correct and not the issue here. It is reference cycles that are the problem. This feature has been requested before, and SR-1807 has been filed for it. (For what it's worth, I started working on this a while ago, and a branch

Re: [swift-evolution] [Pitch] @testable private members

@testable is already a hack. Why not just extend it to fileprivate members? ~Robert Widmann > On Feb 18, 2017, at 1:14 PM, Matthew Johnson via swift-evolution > wrote: > > When writing unit tests sometimes it is necessary to artificially elevate a > member to

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 16, 2017, at 12:30 PM, Rien via swift-evolution > wrote: > > In essence this is about assistance from the compiler that a function marked > ‘pure’ is indeed pure? > I.e. an error message should be generated when a function marked as ‘pure’ is > in fact

Re: [swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

So you've identified the problem, but what do you propose as a solution here? It should be noted that a (non-stdlib) language-level answer to this question has already been discussed and rejected (https://lists.swift.org/pipermail/swift-evolution/2015-December/32.html). ~Robert Widmann

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

~Robert Widmann 2017/02/10 3:35、Tino Heth via swift-evolution のメッセージ: > >> Easy explained - The problem rises indeed not from the added features but >> from the fp group that imposes it’s usage in the Standard libraries and “the >> swifty way”. I like many

Re: [swift-evolution] Compile-time generic specialization

Oh, I see. The constraint solver is picking an overload that better matches the caller rather than the callee's type, which differs from C++ because the template expansion process considers specific-type overloads more specific. We don't consider less-generic prototypes than the caller here

Re: [swift-evolution] Compile-time generic specialization

I don't understand how this change would cause method dispatch to invoke a different prototype. Specialization in either language mentioned doesn't do that. ~Robert Widmann 2017/02/05 11:28、Abe Schneider via swift-evolution のメッセージ: > Hi all, > > The current

Re: [swift-evolution] Either protocol syntax

It sounds like what you want is an GADT-like adaptor gadget to try to bridge between these protocols across these specific types. With general disjuncts you’re subject to the open world assumption - that anybody that should conform to a (visible) protocol, can conform to that protocol - thus

Re: [swift-evolution] Initializers

This seems to contradict Swift’s goal of being safe by default , no? It would make me incredibly uncomfortable if there were a backdoor in DI, even if that backdoor emitted traps when it fails. > On Jan 28, 2017, at 1:07 PM, Victor Petrescu via swift-evolution >

Re: [swift-evolution] The lack of namespaces is leading people astray

I submitted a proposal with TJ a while ago that tried to address this comprehensively because the trouble is if you just want submodules you have to define how our current penta-scheme of access control interacts with each level or do away with a few of them to make some simplifying

Re: [swift-evolution] [Draft] Test-Only Package Dependencies and Targets

> On Jan 30, 2017, at 2:38 PM, Ankit Agarwal wrote: > > > Not in practice (with respect to package manifests). In fact, it seems that, > given there are separate commands (swift build and swift test), separate > directories (Sources and Tests), and separate products, that

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

This seems like it’s running through the same check that disallows defining and calling a closure let randomFunc : () -> () = randomFunc() > On Jan 30, 2017, at 2:37 PM, Michael Gubik via swift-evolution > wrote: > > Example that does not compile: > >

  1   2   3   >