Re: [swift-evolution] [Pitch] Rename Mirror

[Leonardo Pessoa via swift-evolution]

I also don't think this is a worthy change. Mirror can be extended or
even changed in the future to become a true reflection base class. No
benefits added and breaking code are to me a reason to not go forward
with this.

L


On 21 July 2016 at 22:05, Anton Zhilin via swift-evolution
 wrote:
> Somehow I did not send a copy to evolution the first time:
>
> I have to agree. Stopping the discussion on this until after Swift 3.
>
> And response from Dmitri:
>
> Thanks!
>
> Just wanted to be clear -- I am not against reflection.  And I am
> concerned whether the current design of Mirror will work for the
> long-term full-featured reflection implementation, but only because we
> don't know what will be the shape of reflection in Swift.  For
> example, would we be able to call arbitrary public functions on a type
> by name?  If yes, how would that be implemented -- both in the API,
> and on the low level, how would actual function call and argument
> passing work?  How much extra metadata and thunks would the compiler
> need to emit?  Would an average app or framework want that bloat?
> Remember that we don't have a JIT, so we can't say "we will do what
> Java (or any other mainstream language with reflection) does", because
> we can't.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] separate syntax of class inheritance and protocol conformance

[Leonardo Pessoa via swift-evolution]

I don't see this as an issue and I'm sure not comfortable in being
more verbose here or complicating the language unnecessarily. This is
not a change that will bring either benefit or consistency as there
are no other cases to compare the use of colon but these and variable
declarations (which also use only one).

Perhaps a change to Xcode so it could colour differently classes and
protocols could be more benefic with no impact to the language. That
would solve the problem.

L

On 22 July 2016 at 12:13, Karl via swift-evolution
 wrote:
> What about if we defined subclasses with the “subclass” keyword instead of 
> “class”? So you knew the first parameter was always going to be a base class?
>
> That way we keep the single “:” everywhere else - where clauses, generic 
> constraints lists, etc.
>
>> On 22 Jul 2016, at 15:14, Vladimir.S via swift-evolution 
>>  wrote:
>>
>> I remember that this was discussed, but can't find any decision regarding 
>> this.. So, as a last chance, don't we want in Swift 3.0, as big source 
>> breaking change, separate class inheritance and protocol conformance in 
>> syntax?
>>
>> Sorry if there was a decision about this suggestions. Please let know in 
>> this case.
>>
>> I.e. when I see the following I can't understand if the class inherits from 
>> base class and conforms to protocols or just conforms to two protocols:
>>
>> class MyClass : First, Second, Third {
>> }
>>
>> We don't have a rule to name protocols with 'Protocol'/other suffix/prefix, 
>> or classes with 'T'/'C' prefix or something like this, so I believe to 
>> improve the clarity of code we should separate in syntax inheritance and 
>> conformance.
>>
>> As I understand we should discuss changes in these areas:
>>
>> 1. class inheritance :
>> class Child: BaseClass
>>
>> 2. class conformance :
>> class Child: SomeProtocol1, SomeProtocol2
>>
>> 3. class inheritance + conformance :
>> class Child: BaseClass, SomeProtocol1, SomeProtocol2
>>
>> 4. protocol conformance for structs:
>> struct Struct: SomeProtocol1, SomeProtocol2
>>
>> 5. protocol inheritance:
>> protocol Child: BaseProtocol1, BaseProtocol2
>>
>>
>> My suggestions:
>>
>> I) separate inheritance with double colon :
>>
>> 1. class inheritance :
>> class Child:: BaseClass
>>
>> 2. class conformance :
>> class Child: SomeProtocol1, SomeProtocol2
>>
>> 3. class inheritance + conformance :
>> class Child:: BaseClass : SomeProtocol1, SomeProtocol2
>>
>> 4. protocol conformance for structs:
>> struct Struct: SomeProtocol1, SomeProtocol2
>>
>> 5. protocol inheritance:
>> protocol Child:: BaseProtocol1, BaseProtocol2
>>
>>
>> II) in class definition use parenthesis to separate inheritance and 
>> conformance :
>>
>> 1. class inheritance :
>> class Child: BaseClass
>>
>> 2. class conformance :
>> class Child: (SomeProtocol1, SomeProtocol2)
>>
>> 3. class inheritance + conformance :
>> class Child: BaseClass (SomeProtocol1, SomeProtocol2)
>>
>> 4. protocol conformance for structs:
>> struct Struct: SomeProtocol1, SomeProtocol2
>> or
>> struct Struct: (SomeProtocol1, SomeProtocol2)
>> should be discussed
>>
>> 5. protocol inheritance:
>> protocol Child: BaseProtocol1, BaseProtocol2
>>
>>
>> III) special word like 'conforms'
>>
>> 1. class inheritance :
>> class Child: BaseClass
>>
>> 2. class conformance :
>> class Child: conforms SomeProtocol1, SomeProtocol2
>> or
>> class Child conforms SomeProtocol1, SomeProtocol2
>>
>> 3. class inheritance + conformance :
>> class Child: BaseClass conforms SomeProtocol1, SomeProtocol2
>>
>> 4. protocol conformance for structs:
>> struct Struct: conforms SomeProtocol1, SomeProtocol2
>> or
>> struct Struct conforms SomeProtocol1, SomeProtocol2
>>
>> 5. protocol inheritance:
>> protocol Child: BaseProtocol1, BaseProtocol2
>>
>>
>> Thoughts?
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Leonardo Pessoa via swift-evolution]

Matthew, I also thought that way but I think there is no harm in
allowing one to create a subclass if there are no open methods in it,
meaning there is no way a subclass can even replace an existing
implementation. Even if Swift were to allow creating a new method with
the same name of an existing superclass method the new method should
not respond for calls made using the superclass as base. This is
allowed in C# where you can have the following (*dusts off*):

   class A {
  public virtual void method() {
  Console.println("method in A");
  }
   }

   class B : A {
   public final void method() {
  Console.println("method in B");
  }
   }

   class C : B {
   public new void method() {
  Console.println("method in C");
   }
   }

   B b = new C();
   b.method(); // prints "method in B"
   C c = (C) b;
   c.method(); // prints "method in C"

I know I'm being a little flexible here given my previous messages to
this list but if we are to allow subclasses to be openly created,
subclasses will only be allowed to implement new interfaces and create
new methods but not mess with the base implementation unless a method
is explicitly open, there is no harm to the defined contract, so I see
no harm in this approach for composition.

And yes, contracts are about (at least some) control.

L


On 21 July 2016 at 15:08, Matthew Johnson via swift-evolution
 wrote:
>
>> On Jul 21, 2016, at 12:47 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>>
>>
>> on Thu Jul 21 2016, Matthew Johnson  wrote:
>>
 * What is your evaluation of the proposal?
>>>
>>> +1 to the first design.  I think this is a great solution that
>>> balances the many considerations that have been raised on all sides of
>>> this issue.  `open` is 2 characters shorter than `public` so
>>> complaints about boilerplate are no longer valid.  `internal` is the
>>> “default” - neither `public` nor `open` are privileged as a “default”
>>> for publishing API outside of a module.
>>>
>>> I am interested in language enhancements such as exhaustive pattern
>>> matching on classes and protocols which rely on knowledge of the full
>>> class hierarchy.  Such enhancements will be far more useful if the
>>> language supports non-open, non-final classes.
>>>
>>> There are design techniques that would require additional boilerplate
>>> if we cannot have non-open, non-final classes.
>>>
>>> Most importantly, requiring library authors to choose `public` or
>>> `open` provides important documentation value.  Users of the library
>>> will know whether the author intends to support subclasses or not.
>>
>> I think this reasoning is flawed.
>>
>> If you make any methods overridable outside your module (“open”),
>> obviously you mean to allow subclassing outside the module.  If you have
>> no open methods, there's absolutely nothing you need to do to “support
>> subclasses,” and from a design point-of-view, there's no reason to
>> restrict people from subclassing.
>
> I disagree.  As has been discussed when a class is not open the author does 
> not make a commitment to allow subclasses.  The right to make the class final 
> is reserved for the future.  Maybe this is the “nice point of control” you 
> refer to and don’t find compelling?  I would prefer to have library authors 
> acknowledge that they intend to allow subclasses and make that commitment 
> explicit.
>
> For me it isn’t about control as much as it is about making the API contract 
> explicit and acknowledged.  I have wondered about the intent of library 
> authors enough times to find this explicit statement in the language 
> worthwhile.
>
> I also think language features enabled by knowing the whole class hierarchy 
> will provide more value than “compositional subclasses” as long as we gain 
> better support for composition elsewhere in the language.
>
>>
>> The only reasons I can see for allowing people to prevent non-final
>> classes from being subclassed outside the module in which they are
>> defined are:
>>
>> 1. It feels like a nice point of control to have.
>>
>> 2. Marginal performance gains as noted in the proposal
>>
>> I personally don't find these to be convincing.  #1 in particular seems
>> like a poor way to make language design decisions.  If we decide to add
>> this point of control, I'll justify it to myself in terms of #2.
>>
>> P.S., I can live with either alternative; it's just important to me that
>> we understand the situation clearly when evaluating them.
>
> I agree with this.
>
>>
>> HTH,
>>
>> --
>> Dave
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Leonardo Pessoa via swift-evolution]

On 21 July 2016 at 12:33, Chris Lattner via swift-evolution
 wrote:
> Hello Swift community,
>
> The third review of "SE-0117: Allow distinguishing between public access and 
> public overridability" begins now and runs through July 25. The proposal is 
> available here:
>
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
>
> * What is your evaluation of the proposal?

I like the design with open and have no issues with it implicitly
meaning public. After a little confabulation I also believe the
original intent can be achieved by allowing subclassing to be open and
method overriding to be sealed by default, thus providing ground for
composition with no replacing of behaviour as exemplified in the
proposal, so I have no issues with it as long as methods are sealed by
default.

As for the openness of overriden methods, I still believe there should
be a way other than final to reseal the method. Sure there are means
to implement the same without it but not as elegantly IMO.

> * Is the problem being addressed significant enough to warrant a 
> change to Swift?

Yes.

> * Does this proposal fit well with the feel and direction of Swift?

Yes.

> * If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

No.

> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

I've read the proposal and discussed the issue a lot on the threads.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Variadics as Attribute

[Leonardo Pessoa via swift-evolution]

I'm strongly opposed to this too. I'm not only not fond of the
proposed syntax but I also don't really see how allowing other types
in variadics will help anything. Also, there may be necessary more
complex code to support all the extra (or even previously unknown)
types that could be used with this syntax, making the language much
more complex.

L


On 20 July 2016 at 16:54, Chris Lattner via swift-evolution
 wrote:
>
>> On Jul 20, 2016, at 11:37 AM, Haravikk via swift-evolution 
>>  wrote:
>>
>>
>>> On 20 Jul 2016, at 14:55, Tino Heth <2...@gmx.de> wrote:
>>>
>>>
 Am 17.07.2016 um 18:31 schrieb Haravikk :

 I may move discussion of other collection types to its own section though, 
 to make the core proposal as simple as possible, and leave it up to the 
 core team whether to do that part.
>>> imho this is a good idea: Its increased power is a major argument for the 
>>> proposal, but the schedule seems to be very tight already… and I guess the 
>>> discussion about possible problems caused by variadic functions which can 
>>> be called with an explicit collection could be a real distraction, whereas 
>>> the basic idea is so clear that there shouldn't be any valid reasons to not 
>>> accept it.
>>
>> I've created a new pull request for this, you can view the updated file here:
>> https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/-variadics-as-attribute.md
>>
>> Hopefully it's still clear; I know I have a nasty tendency to be overly 
>> verbose with wording and stuff, though the first example should keep the 
>> meat of the proposal straightforward =)
>
> I’m sorry I’m late to this thread, but I’m personally strongly opposed to 
> this.  The problem being solved here is so minor that I don’t see a reason to 
> make a change.  Further, the proposed syntax is so heavy weight that it will 
> adversely affect readability of the API.
>
> -Chris
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

What you said back then lead me to understand you did not get the
difference. Forgive me if it wasn't the case but I've also seen it
happen more than once in this list, hence the repeatition. I also
understand that there are other ways to implement the same behaviour
we want without sealed by default but I wouldn't call a lot of
boilerplate "elegant".

The examples you asked for have already been provided a few times in
this thread and the previous and trying to disqualify them won't make
them go away. And I didn't ask you to prove there is no valid use case
for this; I asked you to give a good technical reason (one that is not
"being able to fix someone elses' code") to keep it as is today, which
is different.

I'm placing my view here that by default would have to mean
non-propagating open to subclasses unless the one writing the subclass
means it too by explicitly keeping it open. To me, meaning (intention)
is the keyword here. I believe there is no need to really introduce a
new keyword for sealed but it will be necessary should open propagates
in order to allow a library extending from another library to re-seal
methods. This is inconsistent with sealed **by default** (that is,
unless stated otherwise).

The core team has already said that this is on, so I think it is a
waste of time to continue trying to disqualify the proposal
altogether. We have to focus on the issues the core team pointed out
that needed solving. Just like David, I also didn't like fileprivate
but I'm not here trying to disqualify it (how long has it been,
actually?). I also liked to know that there are other examples of
languages that follow this model of sealed by default and they work,
even though most of them are little known languages. It's a model to
work with and every language has one; we're just changing Swift's.

L


On 20 July 2016 at 16:05, Michael Peternell <michael.petern...@gmx.at> wrote:
>
>> Am 18.07.2016 um 23:37 schrieb Leonardo Pessoa via swift-evolution 
>> <swift-evolution@swift.org>:
>>
>> Sealed methods can be overriden inside the defined module/library but
>> not outside. Same benefit of classes.
>
> Interesting how the supporters of the proposal seem to imply that the 
> opponents of the proposal don't get the difference between sealed and final. 
> This has happened more than once here.
>
> I know that sealed and final are different, but still I think that sealed has 
> no proper use case that cannot be achieved with final as well (and more 
> elegantly so). Interestingly, no one has yet created a simple example with 
> more than 60 lines of code that demonstrates the use of sealed, and why it is 
> better than final. (Not counting contrived examples with class names like 
> `SomeClass` and similar method names.) I guess that you will not find such a 
> use-case. But who should prove this? Do the opponents of the proposal have to 
> prove that there is no single good use case? Or should the supporters at 
> least demonstrate 2 good use cases (again, non-contrived examples with more 
> than 60 lines of code.) If the supporters are not able to make some good 
> example code with sealed/open, the library developers of the future will not 
> either. I agree with everything Garth said below. I hope for a miracle that 
> the core team will see soon that SE-0117 should be deallocated fast ;) I'm 
> sure we will all learn this in a year or two, when there will be experience 
> with the sealed implementation.
>
> -Michael
>
>>
>> L
>>
>>
>> On 18 July 2016 at 16:32, Garth Snyder via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>>> Nevin/Garth, please remember final and sealed are two different
>>>> concepts: final prevents anyone from subclassing/overriding while
>>>> sealed prevents from subclassing/overriding *outside* the module they
>>>> are declared. Thus final is not the same as sealed.
>>>
>>> No, of course it isn’t. I could well be misguided, but I don’t think I’m 
>>> disoriented. :-)
>>>
>>> Ultimately, the question is whether sealed methods offer any additional 
>>> utility or advantage beyond that of sealed classes plus final. The 
>>> existence of “final” is certainly relevant, as it already provides some, 
>>> but not all, of the features of method-level sealing.
>>>
>>> I’d still like to see a really solid use case that requires the full 
>>> semantics of sealing at the method level.
>>>
>>> Garth
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

[Leonardo Pessoa via swift-evolution]

I'm not very fond of this proposal at all as I don't believe there
will be much gain with it (correct me if I'm wrong but libraries in
Swift are monolithic and nothing to Java, where there is a benefit in
doing this). That said, if this really has to go, Joe's syntax seems
much cleaner but I'd drop the requirement for a dot and implicitly
require anything by omiting the parenthesis. Thus:

   import Swift
   import Swift(Int as MyInt, *)
   import Swift(Int as _, *)

Also supporting this form does not break existing code since the first
option here is how we already do.

L

On 20 July 2016 at 16:08, Xiaodi Wu via swift-evolution
 wrote:
> As Joe and others mentioned in the previous thread, this syntax could be
> greatly simplified in ways that resemble analogous facilities in other
> languages. In particular I think it's alarmingly asymmetrical that, in your
> proposal, `import Swift using (String)` imports *only* String while `import
> Swift hiding (String)` imports *everything but* String. This becomes evident
> when chained together:
>
> ```
> import Swift using (String, Int)
> // imports only String and Int
> import Swift using (String, Int) hiding (String)
> // imports only Int
> import Swift hiding (String, Int)
> // imports everything except String and Int
> import Swift hiding (String, Int) using (String)
> // imports *nothing*? nothing except String? everything except Int?
> confusing.
> ```
>
> By contrast, Joe's proposed syntax (with some riffs) produces something much
> more terse *and* much more clear:
>
> ```
> import Swift.*
> import Swift.(Int as MyInt, *)
> import Swift.(Int as _, *)
> ```
>
>
> On Wed, Jul 20, 2016 at 1:52 PM, Robert Widmann via swift-evolution
>  wrote:
>>
>> Hello all,
>>
>> I’d like to thank the members of the community that have guided the
>> revisions of this proposal.  We have decided to heed the advice of the
>> community and break down our original proposal on modules and qualified
>> imports into source-breaking (qualified imports) and additive (modules)
>> proposals.  As qualified imports is the change most suited to Swift 3, we
>> are pushing that proposal now as our final draft.
>>
>> It can be had inline with this email, on Github, or as a gist.
>>
>> Thanks,
>>
>> ~Robert Widmann
>>
>> Qualified Imports Revisited
>>
>> Proposal: SE-
>> Authors: Robert Widmann, TJ Usiyan
>> Status: Awaiting review
>> Review manager: TBD
>>
>> Introduction
>>
>> We propose a complete overhaul of the qualified imports syntax and
>> semantics.
>>
>> Motivation
>>
>> The existing syntax for qualified imports from modules is needlessly
>> explicit, does not compose, and has a default semantics that dilutes the
>> intended meaning of the very operation itself. Today, a qualified import
>> looks something like this
>>
>> import class Foundation.Date
>>
>> This means that clients of Foundation that wish to see only Date must know
>> the exact kind of declaration that identifier is. In addition, though this
>> import specifies exactly one class be imported from Foundation, the actual
>> semantics mean Swift will recursively open all of Foundation's submodules so
>> you can see, and use, every other identifier anyway - and they are not
>> filtered from code completion. Qualified imports deserve to be first-class
>> in Swift, and that is what we intend to make them with this proposal.
>>
>> Proposed solution
>>
>> The grammar and semantics of qualified imports will change completely with
>> the addition of import qualifiers and import directives. We also introduce
>> two new contextual keywords: using and hiding, to facilitate fine-grained
>> usage of module contents.
>>
>> Detailed design
>>
>> Qualified import syntax will be revised to the following
>>
>> import-decl -> import  <(opt) import-directive-list>
>> import-path -> 
>> -> .
>> import-directive-list -> 
>>   ->  
>> import-directive -> using (, ...)
>>  -> hiding (, ...)
>>
>> This introduces the concept of an import directive. An import directive is
>> a file-local modification of an imported identifier. A directive can be one
>> of 2 operations:
>>
>> 1) using: The using directive is followed by a list of identifiers for
>> non-member nominal declarations within the imported module that should be
>> exposed to this file.
>>
>> // The only visible parts of Foundation in this file are
>> // Foundation.Date, Foundation.DateFormatter, and
>> Foundation.DateComponents
>> //
>> // Previously, this was
>> // import class Foundation.Date
>> // import class Foundation.DateFormatter
>> // import class Foundation.DateComponents
>> import Foundation using (Date, DateFormatter, DateComponents)
>>
>> 2) hiding: The hiding directive is followed by a list of identifiers for
>> non-member nominal declarations within the imported module that should be
>> hidden from this file.
>>
>> // Imports all of Foundation except `Date`
>> import 

Re: [swift-evolution] [Review] SE-0122: Use colons for subscript declarations

[Leonardo Pessoa via swift-evolution]

I like this syntax better. But do you guys think we could remove this
"subscript" prefix? Could we actually bring subscripts closer to
computed properties by doing something like "var self[externaName
internalName : ParamType] : ElemenType"? That could also support the
idea of creating named subscripts by replacing self with another name.

L


On 20 July 2016 at 14:17, Jose Cheyo Jimenez via swift-evolution
 wrote:
>
> On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution
>  wrote:
>
> +1 to clean up the syntax of subscripts. They acts as properties, not
> methods, so it is natural to express them with `:` and not with `->`.
>
> Actually, I'd prefer additional change to use [] instead of () in
> declaration like:
>
> subscript[externalName internalName: ParamType] : ElementType {
>get { … }
>set { … }
> }
>
>
> I got to second this suggestion. To me this is an elegant solution.
>
> If subscripts are so special that Swift decided to give it its own name (as
> oppose to just making it two functions),
> why not declare it in a special way like the above?
>
> I think that in addition to replacing -> with : if we replaced () with []
> then it would be much clearer that this is not a function or property.
>
> subscript[externalName internalName: ParamType] : ElementType {
> get { … }
> set { … }
> }
>
>
> I don’t see another place in the language where [] would make more sense
> than here:
> Otherwise I don’t see  replacing -> with : as a big win like Dmitri Gribenko
> said down thread ->
>
> I think by changing subscripts to use colons we would end in the opposite,
> but
> totally symmetrical situation compared to what we have now.
>
>
>
>
>
> especially if thinking about "Future directions" and confusion with
> parameterised accessor syntax(both declared with `()` but first used with
> `[]` and second with `()`).
>
> On 20.07.2016 8:50, Chris Lattner via swift-evolution wrote:
>
> Hello Swift community,
>
> The review of "SE-0122: Use colons for subscript declarations " begins now
> and runs through July 24. The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the review
> manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a change to
> Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar feature, how
> do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0122: Use colons for subscript declarations

[Leonardo Pessoa via swift-evolution]

On 20 July 2016 at 02:50, Chris Lattner via swift-evolution
 wrote:
> Hello Swift community,
>
> The review of "SE-0122: Use colons for subscript declarations " begins now 
> and runs through July 24. The proposal is available here:
>
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md
>
> * What is your evaluation of the proposal?

I feel a little reluctant to approve this but I'll have to give my +1
just for the sake of consistency. Computed properties already use
colons despite being internally just functions just like subscripts
and the syntax is almost the same. I agree there may be an issue with
readability but so do with computed properties and I didn't see anyone
complaining about that syntax.

> * Is the problem being addressed significant enough to warrant a 
> change to Swift?

Despite accepting the change, I still don't think it is significant
enough. It is merely a cosmetic change that adds/enhances nothing to
the language.

> * Does this proposal fit well with the feel and direction of Swift?

I'm not sure but it grants a bit more of consistency in its syntax.

> * If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

Other languages I worked with make no distinction on how you declare
the type of variables, function returns and properties. I'm not saying
"drop the arrows" thou.

> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Read the proposal and followed the thread discussing it.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Throws, rethrows and declaration-modifiers in function declarations

[Leonardo Pessoa via swift-evolution]

I'm really really sure I don't want to see a `override throwing
mutating func foo()` anywhere. Too much to read and no commas (please,
I'm not saying this as a challenge!).

Additionally, I think `overriden` would make the code much more
english-readable and I'm still not proposing it.

L


On 19 July 2016 at 16:01, Javier Soto via swift-evolution
 wrote:
> I see where you're coming from.
> Without any actual insight into the design of this syntax, I think throws is
> in the position it is because it relates more to the return type of the
> function. Aka a `throws -> T` function can either throw ErrorProtocol OR
> return a T value.
> On Tue, Jul 19, 2016 at 10:51 AM Matthieu Oger via swift-evolution
>  wrote:
>>
>> Hello,
>>
>> I'm currently reading the updated Swift 3 preview book, and was wondering
>> about the `throws` and `rethrows` keywords.
>>
>> In a function declaration, all the keywords are at the beginning, except
>> for `throws` and `rethrows`, which are… oddly placed.
>>
>> In the grammar:
>>
>> ```
>>
>> function-declaration → function-head ­function-name­
>> generic-parameter-clause­opt­function-signature­ function-body­opt­
>>
>> function-head → attributes­opt­declaration-modifiers­opt­func­
>>
>> function-signature → parameter-clause­throws­opt­function-result­opt­
>>
>> function-signature → parameter-clause­rethrows­function-result­opt­
>>
>> ```
>>
>> Is there a reason to have throws and rethrows at this specific position,
>> instead of declaration-modifiers?
>>
>> ie.:
>>
>> This:
>>
>> ```
>> func send() throws -> String {}
>> ```
>>
>> Becomes:
>>
>> ```
>> throwing func send() -> String {}
>> rethrowing func send() -> String {}
>> ```
>>
>> Like:
>>
>> ```
>> mutating func send() -> String {}
>> ```
>>
>> Or:
>>
>> ```
>> throw func send() -> String {}
>> rethrow func send() -> String {}
>> ```
>>
>> Like:
>>
>> ```
>> override func send() -> String {}
>> ```
>>
>> (You can also see the weird difference between `override` and `mutating`,
>> one using the -ing suffix, the other being infinitive)
>>
>> Am I missing something? I find that these keywords break the flow of the
>> function declaration, separating the parameters and the return type, which
>> is never done anywhere else.
>>
>> Thanks.
>>
>> --
>> Matthieu Oger
>> Pixelnest Studio
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> --
> Javier Soto
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

On 18 July 2016 at 16:06, Károly Lőrentey <swift-evolution@swift.org> wrote:
> On 2016-07-18 16:15:10 +, Leonardo Pessoa via swift-evolution said:
>
>> I believe sealed by default applied to functions makes the behaviour
>> consistent with classes and allows for the same behaviour we wanted
>> with this proposal. It would allows us to create subclassable classes
>> in which we would be able to internally override a method but not
>> outside the library and selectively allow other methods to be
>> overriden. Final won't do it so if this is not the default behaviour,
>> it will be necessary to introduce the sealed keyword so we can achieve
>> this.
>
>
> Can you give an example where you'd need such a sealed method, but the
> obvious pattern I described wouldn't work?

I'm not saying your pattern doesn't work; I'm saying it requires more code.

>> It's inconsistent to have to explicitly open a class and
>> explicitly seal its methods and vice-versa. It was my assumption that
>> when we chose sealed by default with the proposal we were talking
>> about everything and not just classes (I at least was talking
>> everything).
>
>
> This was my assumption as well, but then I thought things through. I suspect
> this might be what our friendly review manager was getting at when he gently
> lamented the lack of sufficient discussion on "overridable".
>
>> Introducing "dynamic" or some other keyword to mark explicitly methods
>> that should be overriden is just the same "open" with sealed methods
>> by default would mean for public methods so it makes no difference to
>> me.
>
>
> "dynamic" is already in the language. It changes method dispatch to use
> Objective-C style message passing, enabling advanced techniques based on the
> dynamic runtime, such as method swizzling or KVO. Since it already exists,
> I'm not arguing for its introduction; I merely want it integrated into the
> proposal, in order to keep the language coherent.

When I was talking "dynamic" here, I was meaning as in .NET (dynamic
is required to say a method can be overriden). Perhaps I was misguided
here.

>> Also having no default will not change that some library
>> developers will have everything sealed and selectively open.
>> No default shall also make developers prone to open to think more about
>> the keyword they'll choose to use,
>
>
> Exactly! For this particular corner of the language, it fulfills the
> "unwavering goal of requiring additional thought when publishing a class as
> public API". Forcing people to make an explicit choice is by far the most
> straightforward way to achieve this. It also has the nice property of being
> harder to interpret as a value judgement on overridability, which is clearly
> a topic that gets people's monocles popping. ಠ_ರೃ
>
>> but I'm not fond of no default.
>
>
> If adding an extra qualifier turns out to be an onerous requirement, we can
> choose a default at any time later, without breaking existing code. It'll
> probably be easier to do so once we have a little experience in actually
> using the new language.

So should we drop internal by default too?

>> As for the inheritance of openness, I firmly believe it shouldn't. If
>> a class inherited from an open class is open by default, there will be
>> no libraries making use of other libraries or we should also introduce
>> the sealed keyword in order to make the class (or method) sealed
>> again. This behaviour seems inconsistent to me too.
>
>
> Agreed.
>
>
>>
>> L
>>
>>
>> On 18 July 2016 at 09:07, Károly Lőrentey <swift-evolution@swift.org>
>> wrote:
>>>
>>> On 2016-07-18 09:17:43 +, David Hart via swift-evolution said:
>>>
>>>> On 18 Jul 2016, at 11:11, Xiaodi Wu via swift-evolution
>>>> <swift-evolution@swift.org> wrote:
>>>>
>>>> On Mon, Jul 18, 2016 at 3:27 AM, Brent Royal-Gordon via swift-evolution
>>>> <swift-evolution@swift.org> wrote:
>>>>>
>>>>> On Jul 17, 2016, at 8:57 PM, L. Mihalkovic via swift-evolution
>>>>> <swift-evolution@swift.org> wrote:
>>>>>
>>>>>> On Jul 17, 2016, at 9:14 PM, Garth Snyder via swift-evolution
>>>>>> <swift-evolution@swift.org> wrote:
>>>>>>
>>>>>> Is there a summary somewhere of the motivation for allowing methods to
>>>>>> be declared non-overridable within open classes?
>>>>
>>>> [...]
>>>> Garth: I think it's implicit in th

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

I believe this is not in discussion anymore. We're just debating some
specifics now.

L


On 18 July 2016 at 18:33, John Randolph via swift-evolution
 wrote:
> - infinity for this proposal.
>
> If adopted, it will mean that whenever I want to extend a class implemented 
> by a short-sighted developer, I’ll have to resort to wrappers and classes 
> that own instances of the lobotomized class, etc, etc.
>
> java.lang.string is final.   I will never forgive Gosling for that.
>
> -jcr
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

Sealed methods can be overriden inside the defined module/library but
not outside. Same benefit of classes.

L


On 18 July 2016 at 16:32, Garth Snyder via swift-evolution
 wrote:
>> Nevin/Garth, please remember final and sealed are two different
>> concepts: final prevents anyone from subclassing/overriding while
>> sealed prevents from subclassing/overriding *outside* the module they
>> are declared. Thus final is not the same as sealed.
>
> No, of course it isn’t. I could well be misguided, but I don’t think I’m 
> disoriented. :-)
>
> Ultimately, the question is whether sealed methods offer any additional 
> utility or advantage beyond that of sealed classes plus final. The existence 
> of “final” is certainly relevant, as it already provides some, but not all, 
> of the features of method-level sealing.
>
> I’d still like to see a really solid use case that requires the full 
> semantics of sealing at the method level.
>
> Garth
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

Nevin/Garth, please remember final and sealed are two different
concepts: final prevents anyone from subclassing/overriding while
sealed prevents from subclassing/overriding *outside* the module they
are declared. Thus final is not the same as sealed.

L


On 18 July 2016 at 15:45, Nevin Brackett-Rozinsky via swift-evolution
 wrote:
> Garth makes an excellent point. Károly is correct that we can already
> achieve “sealed” by making a `final` member call through to an `internal`
> one.
>
> Therefore, it seem clear that “open” should only be applicable to classes,
> not to members. This should simplify the proposal nicely.
>
> Nevin
>
>
> On Mon, Jul 18, 2016 at 2:39 PM, Garth Snyder via swift-evolution
>  wrote:
>>
>> > Károly wrote: I suggest we change the proposal to remove the implicit
>> > "sealed" level of public member overridability, and support only "open" or
>> > "final" class members. For members, "open" should mean the opposite of
>> > "final", with no levels in between. Member-level openness should be 
>> > entirely
>> > independent of visibility; so it should be possible to say "internal open"
>> > to mean an internally overridable member that's not at all visible outside
>> > the module -- the same as today's default.
>>
>> What is the distinction between this approach and simply omitting the
>> ability to apply the “open” keyword to anything but a class?
>>
>> The current behavior is (IIUC) that you cannot override a superclass’s
>> final method. Aside from that, you can override any other method that’s
>> visible to you, wherever you stand with regard to the superclass’s origin.
>> If there’s no sealed status for members, why is any change to member
>> annotations needed at all?
>>
>> Garth
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

Then we would need another keyword to close the method again should we
need/want.

   public sealed override func foo()

I don't see any association between override and open/sealed as they
relate to two different aspects of class inheritance. One declares the
method is overriding a superclass method; the other that this method
can(not) be further overriden. With inherited openness, it should be
possible to revert it and defaulting to inherited openness will demand
the introduction of another keword (sealed/closed/nonopen).

It would be simpler to have one global default and one keyword only.
Two keywords add to complexity to learn the language.

L

On 18 July 2016 at 14:12, John McCall via swift-evolution
 wrote:
>> On Jul 17, 2016, at 3:12 PM, Scott James Remnant via swift-evolution 
>>  wrote:
>> I disagree that an `open` method overridden from a superclass is implicitly 
>> `open`.
>>
>> As the rationale for the proposal states, overridability is hard to get 
>> right, and there is no guarantee that the consumer of an API is going to 
>> think about it. The default for override methods should not be `open` or 
>> `final`, it should be the internal equivalent.
>>
>> A coder subclassing a public API, who themselves wants their subclass to be 
>> subclassable, should need to restate `open` where appropriate.
>
> I don't think that defaulting to non-open would be a good idea.  Like I 
> covered in the proposal, inherited open methods remain open; letting an 
> override implicitly close off an open method would create a pretty 
> unfortunate error-of-omission situation.
>
> We could remove the default here and require the method to be explicitly 
> open/nonopen/final, but then we really do pile up the modifiers:
>
>   public open override func foo()
>
> To me, the fact that it's already marked with "override" suggests the 
> possibility of open-ness enough to remove the need to re-state it.  I can see 
> why you might disagree, though.
>
> John.
>
>>
>> This also seems to be a general conflict in that you can always reduce the 
>> access, e.g. an API might have a `public open` method, but the subclass 
>> should be able to declare that as `override private` and thus the `open` 
>> keyword would be invalid in this context.
>>
>>
>> Scott
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

I'll also stick with "open" for both class and methods and I believe
they should be required for both too. Just as I may not design a class
to be subclassable outside my library, I may not want to allow a
method to be overriden outside the library either (but I may want to
override it inside the library). It also produces a consistent
behaviour (sealed by default): if I have to mark a public class
subclassable, why allow every method in this class to be overridable
by default? If not, there would indeed be necessary the introduction
of the "sealed" keyword to ensure we could close overrides on those
public methods.

I'm also not a fan of "public(open)" because that is how the language
seems poluted to me ("public private(set)" anyone? how is that clean?)
and I tend to avoid those at all cost.

L

On 15 July 2016 at 07:46, Haravikk via swift-evolution
 wrote:
>
> On 14 Jul 2016, at 22:39, Chris Lattner via swift-evolution
>  wrote:
>
> To sum this all up, the core team is rejecting this proposal and requesting
> a revision to change the concrete syntax to “public open class Foo” instead
> of “subclassable class Foo".
>
>
> Minor point, but if we're going with the idea of public open and public
> final for declaration, is it worth re-raising the idea of bracketed
> accessibility modifiers? When fileprivate vs private was being discussed I
> was heavily in favour of private(file), private(scope) and private(module)
> (plus private(type) if we get that) to avoid polluting the language with
> more accessibility-specific keywords. This seems like a good time to mention
> it again, as we're now looking at even more keyword pollution:
>
> public(open)
> public(sealed) // Probably not actually defined, but the default for a plain
> "public" declaration
> public(final)
> private(module) // Replaces internal
> private(file)
> private(scope) // Default for plain private
>
> If we get a private(type) that's seven different keyword combinations for
> one feature, so I still very much prefer it being reduced to just
> public/private plus a modifier ;)
>
> This approach satisfies the *unwavering* goal of requiring additional
> thought when publishing a class as public API, makes subclass-ability
> orthogonal to access control, and (admittedly as a bit of a swift-evolution
> process hack) asks the community for an in-depth discussion of the secondary
> points of the proposal: does it make sense to require every member to be
> marked as “overridable” in order to be overridden by an open subclass
> outside of the current module?
>
>
> Personally I'm fine with the proposal's original intent; public open gives a
> clear guarantee that overriding is okay, while plain public produces a
> warning encouraging developers to contact an API author if they choose to
> sub-class it anyway, as it may be unsafe. This lets them leave things
> nominally open, and address only the parts of their API that people actually
> want to sub-class, after all, predicting every possible use-case is a
> non-trivial challenge, and I think it's unreasonable to expect it of
> everyone.
>
> That said, linters should probably highlight public declarations that lack
> open or final; if Xcode had a less obtrusive, purely informational,
> "problem" type then I'd recommend that but that's a separate issue I think.
>
> But yeah, I think it's important to avoid trying to force public open or
> public final only, as that could lead to bad habits with developers just
> defining whichever they feel is easiest, probably leading to loads of types
> that end up being final by default. Better IMO to let developers to define
> things the easy way first, then go back and decide what exactly needs to be
> sub-classable once any implementation issues have been resolved.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

[Leonardo Pessoa via swift-evolution]

I'd agree with Doug, completely out of scope. The only way I'd support
a goto statement was to jump to another switch case as in C#.

L


On 12 July 2016 at 12:49, Douglas Gregor via swift-evolution
 wrote:
>
> On Jul 12, 2016, at 8:47 AM, Erica Sadun via swift-evolution
>  wrote:
>
>
> On Jul 11, 2016, at 4:49 PM, Chris Lattner  wrote:
>
> As for all of the other additive changes, I would strongly prefer you to
> *wait* on even proposing or discussing these things until after the Swift
> 3.0 evolution cycle is done.  Not only is it distracting for the community,
> but the core team and many others won’t be be able to even read the thread
> or the responses, thus your discussion cycle will be lacking key input.
>
> On this topic, we specifically discussed this when labeled breaks were being
> designed, and when they were expanded to “do” in Swift 2.  We specifically
> decided to allow break but not continue, because we didn’t want these
> control flow statements to be “another way to spell a loop”.
>
> -Chris
>
>
> So I can take it as a given that this is out of scope for Swift 3 too?
>
> https://gist.github.com/erica/a78045d09fa5bb20e6e566295140c84d
>
>
> No, *that* is out of scope for *Swift*.
>
> - Doug
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

[Leonardo Pessoa via swift-evolution]

I'll have to give this a -1. Code seems to be confusing with this new
use of continue and we may easily lose control of the flow. If we are
to allow another case to be executed, we should be able to explicitly
direct the flow to the case we want. C# does that using the goto
keyword (yes, I know). I would support this (goto) here but it however
was designed to work well with constant cases and I don't see how this
could work with cases with where expressions like the ones in this
example.

L


On 11 July 2016 at 11:54, Erica Sadun via swift-evolution
 wrote:
>
> On Jul 11, 2016, at 4:49 AM, Ross O'Brien 
> wrote:
>
> I'm in favour of this concept being available in Swift, but it does need to
> make a clear distinction somewhere between a case which matches anything
> (and can catch any fallthrough/continue) and a case which matches none of
> the above. I don't know whether we need to introduce an explicit term for
> this, or whether we make this the distinction between 'case _:' and
> 'default:' (with the side-effect that we can now justify 'default' in the
> language).
>
> For example: let's use this switch to play fizzbuzz.
>
> switch value
> {
>   case x where x % 3 == 0:
> print("fizz")
> continue
>   case x where x % 5 == 0:
> print("buzz")
>   default:
> print(value)
> }
>
> I know this is a trivial example, but it's also a frequent example used to
> teach switch to programmers.
> The keywords in play are 'continue' and 'default'. A multiple of 5 but not 3
> will print 'buzz' and be done. A multiple of 3 and 5 will print 'fizz buzz'.
> Any number not a multiple of 3 or 5 will say its value. Crucially, a
> multiple of 3 but not 5 will say fizz, won't say buzz, and won't say the
> number itself - whereas if we used 'case _', it would say fizz and then the
> number itself.
>
>
>
> The standard question asks you to print the value and then fizz and/or buzz
> on the same line and then move to the next line.
>
> If you use the rules you stated ("Any number not a multiple of 3 or 5 will
> say its value."), it would look like this:
>
> switch value
> {
> case _ where !(x % 5 == 0 || x % 3 == 0):
> print(value)
> case x where x % 3 == 0:
> print("fizz", terminator: "")
> continue
> case x where x % 5 == 0:
> print("buzz", terminator: "")
> continue
> default:
> print("")
> break
> }
>
> If you use the standard rules, it looks like this:
>
> switch value
> {
> case _:
> print(value, terminator: "")
> case x where x % 3 == 0:
> print(" fizz", terminator: "")
> continue
> case x where x % 5 == 0:
> print(" buzz", terminator: "")
> continue
> default:
> print("")
> break
> }
>
> -- E
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

Jean, given this proposal it will be possible if the developer of the
library intends so. You'll have to have unsealed classes to be able to
subclass them and unsealed methods so you can override. It is possible
to just allow subclassing without allowing overriding, just like
final.

As for conflicts I don't think so. If you declare a new method with
the same name as an existing one without overriding, it will become a
new method and the base class won't even know that new method exists.
C# allows this but uses the keyword new (instead of override) to
clarify a new method is being introduced instead of the existing one
but as far as I see there is no such need in Swift. I'm also not sure
we can override a method inside an extension but if so, this provides
a new point of extension inside a class that is not subclassable.

L


On 11 July 2016 at 11:21, Jean-Daniel Dupas via swift-evolution
 wrote:
> Just a though, but why sealed classes have to be completely unsubclassable ?
>
> Wouldn't it be possible to allow the user to subclass sealed class, but deny
> overriding of any public member.
>
> I see a use case where a user want to extends an existing model by adding
> new properties and new methods to an object but can’t use composition
> because doing that will prevent to pass that object to the framework that
> expect the base object.
>
> That would let user override existing class to extends them, but should not
> cause any side effect in the way the class should behave, and so would not
> affects preconditions and postconditions, and should not prevent
> optimization in whole module compilation, as the methods of the base class
> are considered final outside of the module.
>
> Of course, it will introduce some fragility in the library, as adding new
> methods may conflict with user subclass methods, but no more than what would
> append if the user write extension to add new methods to the model.
>
> Le 11 juil. 2016 à 05:38, Jordan Rose via swift-evolution
>  a écrit :
>
> [Proposal:
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> ]
>
> (This is my second response to this proposal. The previous message shared a
> use case where public-but-non-subclassable made things work out much better
> with required initializers. This one has a bit more ideology in it.)
>
> As many people have said already, this proposal is quite beneficial to
> library designers attempting to reason about their code, not just now but in
> the future as well. The model laid out in the Library Evolution document
> (often referred to as “resilience”) supports Swift libraries that want to
> preserve a stable binary and source interface.
>
> In the Swift 2 model (and what’s currently described in that document), a
> public class must be final or non-final at the time it is published. It’s
> clearly not safe to add ‘final' in a later version of the library, because a
> client might already have a subclass; it’s also not safe to remove ‘final’
> because existing clients may have been compiled assuming there are no
> subclasses.
>
> (Of course, we can remove this optimization, and make ‘final’ a semantic
> contract only. I’m deliberately avoiding most discussion of performance, but
> in this parenthetical I’ll note that Swift makes it possible to write code
> that is slower than Objective-C. This is considered acceptable because the
> compiler can often optimize it for a particular call site. For those who
> want more information about the current implementation of some of Swift’s
> features, I suggest watching the “Understanding Swift Performance” talk from
> this year’s WWDC.)
>
> With this proposal, a public class can be non-publicly-subclassable or
> publicly-subclassable. Once a class is publicly-subclassable (“open”), you
> can’t go back, of course. But a class that’s not initially open could become
> open in a future release of the library. All existing clients would already
> be equipped to deal with this, because there might be subclasses inside the
> library. On the other hand, the class can also be marked ‘final’, if the
> library author later realizes there will never be any subclasses and that
> both client authors and the compiler should know this.
>
> One point that’s not covered in this proposal is whether making a class
> ‘open’ applies retroactively, i.e. if MagicLib 1.2 is the first version that
> makes the Magician class ‘open’, can clients deploy back to MagicLib 1.0 and
> expect their subclasses to work? My inclination is to say no; if it’s
> possible for a non-open method to be overridden in the future, a library
> author has to write their library as if it will be overridden now, and
> there’s no point in making it non-open in the first place. That would make
> ‘open’ a “versioned attribute” in the terminology of Library Evolution,
> whatever the syntax ends up being.
>
> ---
>
> Okay, so why is this 

Re: [swift-evolution] [Pitch] Extending Swift Literals

[Leonardo Pessoa via swift-evolution]

I'm also not in for this. As mentioned before, these don't seem like
literals but some sort of masking shortcut to other framework's calls to
create the given objects. I think I could go only for colour literals here
but if its literal representation were something close to HTML's.

L

On Monday, 11 July 2016, Daniel Steinberg via swift-evolution <
swift-evolution@swift.org> wrote:

> (Forgot to copy the list)
>
> If what you’re after is cross platform code, then I would rather see types
> such as Color be standardized to represent a UIColor/NSColor on the
> appropriate platform.
>
> Although literals have this benefit, that seems to be a secondary feature
> of them to me.
>
> Wanting that aspect of literals is, in my opinion, an API request not a
> language request.
>
> Best,
>
> Daniel
>
>
>
> On Jul 11, 2016, at 1:53 AM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org
> > wrote:
>
> On Jul 10, 2016, at 11:43 PM, Zach Waldowski via swift-evolution <
> swift-evolution@swift.org
> > wrote:
>
>
> I share the concern with others about the usefulness of these, but I also
> like your note about standardizing syntax, and really like that these merge
> together all the different syntaxes for literals we've seen.
>
>
> Literals enable you to write cross platform code with a minimum of
> redundant and platform-configured code.
>
> In today's Swift, you can say:   let myColor = color literal and that code
> is
> cross-compatible for all Apple platforms, whether UIColor, NSColor, and
> SKColor.
> If you write that same request as let myColor = UIColor(...), it will no
> longer
> compile on Cocoa.
>
> I'm proposing to extend these existing behaviors to create common code
> inherently
> universal tasks with common structure: NSFont/UIFont,
> point2/CGPoint/NSPoint, etc
>
> To that end, I'd like to modestly suggest that #literal.foo (as already
> written in the proposal) should be the canonical form of a literal in
> source text, whereas #foo is the one you see used in the code editor.
>
>
> I've already filed radars asking that the code editor let you see the raw
> unrendered literals
> and heartily encourage duped radars to support that end.
>
> I'm not a fan of namespacing in #literal, because every literal should
> obviously be a literal; I wouldn't ever recommend numerals fall under this
> proposal as written, for instance.
>
>
> The core team has suggested they'd like to use namespacing, especially
> with related
> items that could otherwise spread and grow in an unmanaged way.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>

-- 
L
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes tobenon-subclassable publicly

[Leonardo Pessoa via swift-evolution]

Yes, app. Apps can be extended through plugins and you cannot write a plugin to 
an app without a library that exposes what you can do. That alone can expand my 
simple sample into a variety of examples: plugins.

For the many types of folders I cannot enter details of my app now but check 
macOS' folders: aside the basics you have smart folders, disks, remote folders 
and so forth. They follow the same basics but some specificities will vary. You 
can create as many different files you want but can you create a new type of 
folder there? Same here.

Too bad my example did not convince you but subclassing to fix bugs also don't 
convince me. I really believed this is the behaviour that leads bugs in a 
library not to be fixed: because instead of helping improving the library for 
everyone you fix it for yourself and let it go. The developer of the library 
doesn't even care to fix the bug since everyone uses your subclass fix or he 
finds out purple doing this, fixes the bug and puts a final there breaking 
everyone's app.

L

-Original Message-
From: "Tino Heth" <2...@gmx.de>
Sent: ‎10/‎07/‎2016 05:47 PM
To: "Leonardo Pessoa" 
Cc: "swift-evolution" ; "Jean-Daniel Dupas" 

Subject: Re: [swift-evolution] [Review] SE-0117: Default classes 
tobenon-subclassable publicly



Should I assume then you want so much this proposal to be dropped you didn't 
even mind to look for the example so you wouldn't have to admit this proposal 
is needed? Fine, here is the whole of that example.

This list has thousands of messages, this topic alone is split into at least 
six threads… I tried, but how much time should I spend searching without any 
helpful hint?
But let's see what we got now...


I'm currently working on an app 
wait a minute: An app, not a library? What difference will sealed make here at 
all?


which will have object representations of Files and Folders (both come from a 
common class called Entry). You as a developer for this system will be entitled 
to extend from File and Entry freely but you can only work with Folders and its 
subclasses (specialised folders) but to this system it is important you don't 
subclass any type of folder. Without this proposal I would have to create 
workarounds to prevent you from doing that while still allowing me to subclass 
while playing a lot of finals everywhere. And so far I would have to allow you 
to subclass Folder itself (at least) but you would complain (and possibly file 
a bug report to me) because it would not be working properly because your 
classes would not benefit from the workaround. In this case, if I could 
subclass internally but prevent you from doing it, you could complain I'm not 
allowing you to do whatever you want but you wouldn't complain my code doesn't 
work properly (it does, you just won't know it).

So, how many types of directories may exist that you would have to mark as 
final? (serious question — please don't ignore it)
I don't know about you specific model, but for me, invisible directories and 
bundles would be all I'd be worried about — and those are basically all normal 
folders as well…
So, do those subclasses each have special properties? There is only a limited 
set of metadata a directory can have, so I expect there is no need for 
subclassing at all: Is there a special reason why it can't be a single class, 
or an enum?
This may all be useless advice that doesn't work for your case — but if I stick 
with the Sasquatch-metapher, this is a very blurred picture...


IMO libraries are to be written with intention in mind and I don't think it is 
right to use a library written to compose a PDF file to send an email (even if 
you're sending the PDF file attached, the right way to do it is by composition 
not subclassing).

How is this statement connected to the proposal?
The only way to prevent misuse of software is not to write it; and what harm is 
done to you as the author of a PDF-lib (btw: been there, done that — nasty 
format ;-) if some stupid user turns your composer into Emacs?


Additionally, someone mentioned and I went in to check about a recommendation 
for Java to intentionally document and enable classes to be subclasses 
explicitly otherwise forbid it at all and that recommendation seems to come 
from Oracle itself. I believe Oracle would do it to Java if it had great 
interest in it without consulting anyone's opinion.

good point… Oracle is widely known for its instinctive knowledge about the 
needs and problems of their customers — which they than tend to ignore and do 
something different ;-) 


About the addition to the proposal to enable force unsealing, I'm completely 
opposed as it is just like not having any of this protection at all (why 
putting a lock on the door to your house if the key is under the mat?)

As long as we don't speak about commercial libraries, which are a curiosity in 
the Swift-cosmos:
There is no lock, there 

Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

[Leonardo Pessoa via swift-evolution]

You asked me to correct you and I shall: you're wrong. Although it seems like a 
filesystem representation here, this is not it and the subclassability of Entry 
and File is intended but Folder is a special type and I cannot allow more than 
the base type and a few controlled subclasses due to the nature of the system. 
It was intended to be exactly like this and there was nothing incidental about 
them. IMO a well designed library is like an app with plugins: you're not 
entitled to do whatever you want in the app through a plugin but the app 
controls and dictates what it allows you to do.

You asked for an example where this feature would be needed and I've provided. 
As I said, a concrete and real example. But I haven't seen anyone give the 
slightest concrete technical reason not to approve it and please don't come 
saying fix bugs in a library by subclassing because that's not what subclassing 
is for. That is a misuse of object orientation in whichever language you're 
working with.

L

-Original Message-
From: "Garth Snyder via swift-evolution" 
Sent: ‎10/‎07/‎2016 05:47 PM
To: "swift-evolution" 
Subject: Re: [swift-evolution] [Review] SE-0117: Default classes to 
benon-subclassable publicly

Tino Heth wrote: ...I challenged [supporters] to show a singe persuasive 
example to illustrate that this proposal could actually improve 
something...even if there are cases which cannot be repelled with the simple 
advice "just don't subclass", this would only be a basis to start talking about 
the actual pros and cons.


Leonardo Pessoa responded: ...an app which will have object representations of 
Files and Folders (both come from a common class called Entry). You [can] 
extend from File and Entry freely but...it is important you don't subclass any 
type of Folder. Without this proposal I would have to create workarounds to 
prevent you from doing that while still allowing me to subclass while playing a 
lot of finals everywhere. And so far I would have to allow you to subclass 
Folder itself (at least) but you would complain (and possibly file a bug report 
to me) because it would not be working properly because your classes would not 
benefit from the workaround. In this case, if I could subclass internally but 
prevent you from doing it, you could complain I'm not allowing you to do 
whatever you want but you wouldn't complain my code doesn't work properly (it 
does, you just won't know it).



To me, this scenario seems like an example of why the proposal should be 
rejected.


Correct me if I’m wrong, but your (Leonardo’s) narrative suggests that the 
subclassability of File and Entry is incidental. If the intent was actively to 
allow people to provide their own implementations of filesystem objects, you 
would presumably have taken whatever steps were necessary to make Folder 
subclassable as well.


This scenario ends up defining a perfectly commonplace mix of classes. Some of 
them behave reasonably when subclassed and some don’t. The question is, should 
Swift — as a matter of default policy and community style — actively push you 
to seal ALL of these classes?


No, it shouldn’t. You’d be removing the possibility of functionality that’s 
potentially useful to some clients, without gaining much in return.


A “sealed” keyword or equivalent seems plausible, but it shouldn’t be the 
default. 


Even an affirmative “sealed" feels prone to abuse, however. In this case, for 
example, I would imagine there would be considerable temptation to mark all 
objects (Entry, File, Folder, etc.) as sealed, just because Folder needs it. 
API designers (and clients!) dislike unexplained asymmetry.


Garth___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

[Leonardo Pessoa via swift-evolution]

Should I assume then you want so much this proposal to be dropped you didn't 
even mind to look for the example so you wouldn't have to admit this proposal 
is needed? Fine, here is the whole of that example.

I'm currently working on an app which will have object representations of Files 
and Folders (both come from a common class called Entry). You as a developer 
for this system will be entitled to extend from File and Entry freely but you 
can only work with Folders and its subclasses (specialised folders) but to this 
system it is important you don't subclass any type of folder. Without this 
proposal I would have to create workarounds to prevent you from doing that 
while still allowing me to subclass while playing a lot of finals everywhere. 
And so far I would have to allow you to subclass Folder itself (at least) but 
you would complain (and possibly file a bug report to me) because it would not 
be working properly because your classes would not benefit from the workaround. 
In this case, if I could subclass internally but prevent you from doing it, you 
could complain I'm not allowing you to do whatever you want but you wouldn't 
complain my code doesn't work properly (it does, you just won't know it).

There may be several more examples but this is one I'm facing right now, so I 
can assure you it is a true example. IMO libraries are to be written with 
intention in mind and I don't think it is right to use a library written to 
compose a PDF file to send an email (even if you're sending the PDF file 
attached, the right way to do it is by composition not subclassing).

Additionally, someone mentioned and I went in to check about a recommendation 
for Java to intentionally document and enable classes to be subclasses 
explicitly otherwise forbid it at all and that recommendation seems to come 
from Oracle itself. I believe Oracle would do it to Java if it had great 
interest in it without consulting anyone's opinion.

About the addition to the proposal to enable force unsealing, I'm completely 
opposed as it is just like not having any of this protection at all (why 
putting a lock on the door to your house if the key is under the mat?)

Swift doesn't have to follow on the footsteps of any language but what is best 
for the intention the language was created for. If sealed by default goes in 
that direction, then we should have it not looking back. The same goes if we 
decide this is not taking the language in its intended direction. If I'm not 
wrong at least one member of the core team already mentioned in this thread 
this is completely aligned with the intention of the language, so I think we 
should give it a go and stop trying to have/keep control of everything we touch.

L

-Original Message-
From: "Tino Heth via swift-evolution" 
Sent: ‎10/‎07/‎2016 01:55 PM
To: "swift-evolution" 
Cc: "Jean-Daniel Dupas" 
Subject: Re: [swift-evolution] [Review] SE-0117: Default classes to 
benon-subclassable publicly

Two days ago, I challenged the supporters of this proposal to show a singe 
persuasive example to illustrate that this proposal could actually improve 
something.
I got a single reply — which did not contain an example, but just the claim 
that there is one…
Imho that alone should be enough to cancel the whole thing, because even if 
there are cases which cannot be repelled with the simple advice "just don't 
subclass", this would only be a basis to start talking about the actual pros 
and cons.

So for me, the promised benefits are less likely than the existence of Bigfoot:
I guess there are at least several hundred people who swore they have seen him, 
and there are even some blurry photos ;-)

Of course, it is impossible to come up with an unquestionable argument for the 
change — and it's also impossible to prove the opposite, because the whole 
debate makes as much sense as arguing wether raisins are tasteful or terrible; 
it's nothing but personal preference, and the only thing we can hope for is 
that the bias of those who will decide this proposal isn't at odds with the 
needs of the majority.

If we can agree that it is not about facts, but about opinion, there are still 
fundamental arguments against SE-0117:
Those who have issues with subclassing can just resign from it (as users of a 
library), and they can annotate their classes to dictate their usage (as an 
author) — but if you think subclassing is still a good tool, you can't do 
anything with a sealed class.
Additionally, please note that those who ask for stricter rules and more 
regulation have many reasons to be happy with the status quo:
You can subclass neither structs nor enums, and by default, you can't inherit 
from a framework-class as well, because it is internal — and yet they yell for 
more.

Swift claims to be opinionated, not to aim for compromise — but if plain old OO 
isn't compatible with the ideals of the language, it 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

I've sent one I currently have myself. Look back on the thread posts.

L


On 8 July 2016 at 18:14, Tino Heth via swift-evolution
 wrote:
>
> When was the last time you you thought "I really wish the author of that
> library had restricted my options to use it"?
>
>
> I really wish Objective-C had this feature from the start.  I believe there
> would have been significant benefits to Apple's platforms and ecosystem.
> The reasons for believing (or not believing) this have been discussed in
> depth so there isn't a need to rehash them now.
>
> I'm not asking for reasons but for a single persuasive example…
>
> It is easy to claim that everything will be better if we add restrictions,
> but so far, I haven't heard of any real problems cause by the current
> defaults:
> The motivation to change them is not because of actual experience, it's just
> the trendy opinion that inheritance is evil.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Variadics as Attribute

[Leonardo Pessoa via swift-evolution]

I meant only for the sake of variadics. That would "teach" the
compiler to read "func x(args : Int...)" from our code and interpret
it too as "func x(args ; [Int])" thus accepting lists of arguments or
an array with the arguments with no additional effort from our part.

L

On 8 July 2016 at 17:29, Kristóf Liliom  wrote:
> I think if Int... === [Int] would be true, then it would introduce a new set 
> of ambiguity and defaulting to a specific behaviour would be a "good guess" 
> rather than a reliable logic.
>
> Best,
> Kristóf
>
>> On 08 Jul 2016, at 22:24, Leonardo Pessoa  wrote:
>>
>> Kristof, this is the closest to what I've been proposing but I'm
>> really unable to understand why it is to had to just change the
>> compiler to recognise an array passed as argument to a variadic
>> argument. No need for any extra keywords or complicated solutions,
>> just make the compiler recognise that "Int... === [Int]" and we have
>> the issue solved: it accepts both and array of ints or multiple ints
>> in its arguments.
>>
>> L
>>
>> On 8 July 2016 at 17:18, Kristóf Liliom  wrote:
>>> Hi!
>>>
>>> I read through this proposal, and I have the feeling that we are trying to
>>> solve an issue with Swift from the wrong angle. IMHO Swift has one of the
>>> best implementations of variadics which has only one major downfall: passing
>>> an array as a variadic argument is not possible. Maybe it would be a better
>>> idea to leave method declarations as is and only change the call-site as
>>> something like this:
>>>
>>> func someMethod(_ values:Int...) { /* values: 1, 2, 3, 4 */ }
>>>
>>> func someMethod2(_ values:Int...) {
>>>someMethod(#unpack(values)) // Or #variadic
>>> }
>>>
>>> someMethod2(1, 2, 3, 4)
>>>
>>> This would tell the compiler to pass the array's values. Maybe in a more
>>> advanced scenario, even this could be supported:
>>>
>>> func someMethod(_ values:Int...) { /* values: -1, -2, 1, 2, 3, 4, -3, -4 */
>>> }
>>>
>>> func someMethod2(_ values:Int...) {
>>>someMethod(-1, -2, #unpack(values), -3, -4) // Or #variadic
>>> }
>>>
>>> someMethod2(1, 2, 3, 4)
>>>
>>> I know this is not a well defined idea, but please give it a thought, could
>>> it be a feasible solution to this problem?
>>>
>>> Best,
>>> Kristóf
>>>
>>> On 08 Jul 2016, at 13:43, Haravikk via swift-evolution
>>>  wrote:
>>>
>>>
>>> On 8 Jul 2016, at 12:03, Leonardo Pessoa  wrote:
>>> You would have to add some extra code on the compiler to check whether you
>>> can use that type for your variadics argument and may incur in more changes
>>> to enable handling different classes possible.
>>>
>>>
>>> Not really; the variadic call just needs to be treated as if it is an array
>>> literal, at which point the compiler will either match a method or it won't.
>>> The only real difference is that when called as a variadic the compiler will
>>> only match functions with the @variadic attribute. In other words the
>>> following resolve in much the same way:
>>>
>>> someMethod([1, 2, 3, 4, 5, 6]) // Looks for a declaration of someMethod()
>>> that can take an array literal
>>> someMethod(1, 2, 3, 4, 5, 6) // Looks for a declaration of someMethod() that
>>> can take an array literal, and has a @variadic parameter
>>>
>>> Treating the trailing ellipsis as a shorthand for [Foo] is no different in
>>> that respect, it's just limited to Array only. In other words, if an array
>>> literal cannot be accepted by the parameter, then it cannot have the
>>> @variadic attribute, we'd need a compiler expert to comment but I don't
>>> think that should be that hard to check (concrete types will be checked for
>>> conformance to ArrayLiteralConvertible, and generics will be checked to see
>>> if they can be fulfilled by an Array or some kind of ArrayLiteral type).
>>>
>>> Really what it comes down to is a choice between two methods of solving the
>>> array passing problem:
>>>
>>> Variadic function treated as regular function with array parameter.
>>> Regular function gains ability to be called (optionally) in variadic style
>>> at call site.
>>>
>>>
>>> But my preference is for the latter as it eliminates the variadic function
>>> declarations as being some kind of special case, and moves it into a feature
>>> of regular function declarations.
>>>
>>> I would also expect to be able to use dictionaries as variadics with this
>>> syntax, and that would be confusing too.
>>>
>>>
>>> This should only be the case I think if you've extended Dictionary with an
>>> ArrayLiteralConvertible initialiser, or you declared your function to take a
>>> generic iterator/sequence/collection with elements of type (Key, Value) in
>>> which case, yes, a Dictionary could fulfil the requirements.
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> 

Re: [swift-evolution] [Proposal] Variadics as Attribute

[Leonardo Pessoa via swift-evolution]

Kristof, this is the closest to what I've been proposing but I'm
really unable to understand why it is to had to just change the
compiler to recognise an array passed as argument to a variadic
argument. No need for any extra keywords or complicated solutions,
just make the compiler recognise that "Int... === [Int]" and we have
the issue solved: it accepts both and array of ints or multiple ints
in its arguments.

L

On 8 July 2016 at 17:18, Kristóf Liliom  wrote:
> Hi!
>
> I read through this proposal, and I have the feeling that we are trying to
> solve an issue with Swift from the wrong angle. IMHO Swift has one of the
> best implementations of variadics which has only one major downfall: passing
> an array as a variadic argument is not possible. Maybe it would be a better
> idea to leave method declarations as is and only change the call-site as
> something like this:
>
> func someMethod(_ values:Int...) { /* values: 1, 2, 3, 4 */ }
>
> func someMethod2(_ values:Int...) {
> someMethod(#unpack(values)) // Or #variadic
> }
>
> someMethod2(1, 2, 3, 4)
>
> This would tell the compiler to pass the array's values. Maybe in a more
> advanced scenario, even this could be supported:
>
> func someMethod(_ values:Int...) { /* values: -1, -2, 1, 2, 3, 4, -3, -4 */
> }
>
> func someMethod2(_ values:Int...) {
> someMethod(-1, -2, #unpack(values), -3, -4) // Or #variadic
> }
>
> someMethod2(1, 2, 3, 4)
>
> I know this is not a well defined idea, but please give it a thought, could
> it be a feasible solution to this problem?
>
> Best,
> Kristóf
>
> On 08 Jul 2016, at 13:43, Haravikk via swift-evolution
>  wrote:
>
>
> On 8 Jul 2016, at 12:03, Leonardo Pessoa  wrote:
> You would have to add some extra code on the compiler to check whether you
> can use that type for your variadics argument and may incur in more changes
> to enable handling different classes possible.
>
>
> Not really; the variadic call just needs to be treated as if it is an array
> literal, at which point the compiler will either match a method or it won't.
> The only real difference is that when called as a variadic the compiler will
> only match functions with the @variadic attribute. In other words the
> following resolve in much the same way:
>
> someMethod([1, 2, 3, 4, 5, 6]) // Looks for a declaration of someMethod()
> that can take an array literal
> someMethod(1, 2, 3, 4, 5, 6) // Looks for a declaration of someMethod() that
> can take an array literal, and has a @variadic parameter
>
> Treating the trailing ellipsis as a shorthand for [Foo] is no different in
> that respect, it's just limited to Array only. In other words, if an array
> literal cannot be accepted by the parameter, then it cannot have the
> @variadic attribute, we'd need a compiler expert to comment but I don't
> think that should be that hard to check (concrete types will be checked for
> conformance to ArrayLiteralConvertible, and generics will be checked to see
> if they can be fulfilled by an Array or some kind of ArrayLiteral type).
>
>  Really what it comes down to is a choice between two methods of solving the
> array passing problem:
>
> Variadic function treated as regular function with array parameter.
> Regular function gains ability to be called (optionally) in variadic style
> at call site.
>
>
> But my preference is for the latter as it eliminates the variadic function
> declarations as being some kind of special case, and moves it into a feature
> of regular function declarations.
>
> I would also expect to be able to use dictionaries as variadics with this
> syntax, and that would be confusing too.
>
>
> This should only be the case I think if you've extended Dictionary with an
> ArrayLiteralConvertible initialiser, or you declared your function to take a
> generic iterator/sequence/collection with elements of type (Key, Value) in
> which case, yes, a Dictionary could fulfil the requirements.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

Just to relax a bit, from reading this thread I cannot help but feel a
relation to Civil War. One can even say on which side everyone here
would stand for real. #TeamIronMan

L

On 8 July 2016 at 15:13, Matthew Johnson via swift-evolution
 wrote:
>
>
> Sent from my iPad
>
> On Jul 8, 2016, at 12:30 PM, Tino Heth <2...@gmx.de> wrote:
>
>
> 1. As you point out, the majority of the surface area of idiomatic Swift
> APIs are unlikely to be impacted (value types, protocols, and final
> classes).  This is very likely to apply to future Swift-native APIs from
> Apple regardless of the outcome of this proposal.
>
> 2. There is no impact on users of Apple's Objective-C APIs (AFAICT).
>
> In the context of these facts, this proposal is not nearly as dramatic a
> change as many seem to be suggesting.
>
> It is dramatic, and your whole argument is flawed because you miss the imho
> most important point.
>
>
> I didn't say it isn't dramatic, only that it isn't as dramatic a change as
> some commenters seem to suggest.
>
> This is not only a question of "will I be able to override this tiny method
> of UIView in the future?", but a question of attitude:
> When you do away with the rule of lenity and change it to "guilty by
> default", the direct impact is marginal as well — but it is a drastic change
> for the society as a whole.
>
>
> It's not about guilt or innocence, or any kind of lenience or punishment.
>
> It's mostly about whether we want to foster an ecosystem where public API
> contracts have been explicitly considered or not.  There are some ancillary
> benefits as well but those are much less important.
>
>
> Defaults matter, because they transmit a message:
>
>
> I agree.
>
> Every rule and obstacle we add to Swift is a statement that says "we favor
> bureaucracy over freedom", and this will affect the community evolving
> around the language.
> When you use a library in a way that wasn't anticipated by its author,
> you'll ran into issues occasionally; nonetheless, I think we should struggle
> for an open ecosystem that encourages others to experiment and fail, rather
> than to limit their possibilities in a futile attempt to protect them.
>
>
> In a majority of cases today this openness is better fostered by Github than
> "anything goes" public API.
>
>
> Everyone should ask himself a simple question:
> When was the last time you you thought "I really wish the author of that
> library had restricted my options to use it"?
>
>
> I really wish Objective-C had this feature from the start.  I believe there
> would have been significant benefits to Apple's platforms and ecosystem.
> The reasons for believing (or not believing) this have been discussed in
> depth so there isn't a need to rehash them now.
>
> As a matter of fact, open by default forces nobody to subclass and override,
> so it's easy to avoid any problems caused by excessive hacking — closed by
> default, on the other hand, has impact not only on those who believe in
> restrictions, but on those who dislike them as well.
>
>
> Actually open by default has caused some very nontrivial difficulties for
> Apple's framework maintainers.  We all pay the price for this whether we
> engage in such subclassing and overriding or not.  I find that pretty
> unfortunate, especially for those of us who do find other ways to solve our
> problems.
>
> -Matthew
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Allow injection of `didSet` and `willSet`

[Leonardo Pessoa via swift-evolution]

+1. This would allow us to create observers on any foreign variable. I'm
far from a compiler right now but I wouldn't this syntax create a new
variable instead of observing an existing one? Even if not, by reading
this one could be mislead to believe so. Perhaps you should give it
something to differentiate from creating a new var, for example by
suppressing the type on this declaration.

On Friday, 8 July 2016, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello dear Swift community, I’m not sure if this was discussed before or
> not, but I really want to know if something like this is welcome for the
> future Swift version. If this topic was already discussed, I’m apologizing
> for bringing it back to life in a new thread.
>
> Lets say I’ve got a third party module and I want to know when the a
> variable of some type has changed:
>
> extension UIViewController {
>
> public override var view: UIView {
>
> willSet {
> // do something useful here
> }
>
> didSet {
> // do something useful here
> }
> }
> }
>
> Wouldn’t be handy to inject custom didSet and willSet functions into any
> property or computed property?
>
> This would also allow us to build a proper two-way-binding mechanism.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
>

-- 
L
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Variadics as Attribute

[Leonardo Pessoa via swift-evolution]

It is definitely not hard to solve any issues here (if you consider only
the basic variadics). Int... is nothing more than [Int], so essentially

   func doSomething(args : Int...)

is also just

   func doSomething(args : [Int])

We just have to think of it like some form of function overloading and the
compiler can automatically handle that.

As for enabling usage of other types as the result of variadics, I don't
see how that can be a benefit (unless you're just trying to write little
bit less on your own code). You would have to add some extra code on the
compiler to check whether you can use that type for your variadics argument
and may incur in more changes to enable handling different classes
possible. I would also expect to be able to use dictionaries as variadics
with this syntax, and that would be confusing too.

Should this pass like it is, it would not surprise me if my apps take more
time to compile. Now, if the problem is just being able to pass an array to
a variadics argument, my solution is cleaner, incur in less changes to the
language and is backwards compatible.

L

On Friday, 8 July 2016, Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 8 Jul 2016, at 10:31, Pyry Jahkola  > wrote:
>
> If you take this function for example,
>
> func printThem(@variadic _ values: [Any])
>
> then what would `values` be in the following calls, and why?
>
> printThem() // clearly []
> printThem(1) // clearly [1]
> printThem(1, 2) // clearly [1, 2]
> printThem([1], [2]) // clearly [[1], [2]]
> printThem([]) // [] or [[]], which one?
> printThem([1]) // [1] or [[1]]?
> printThem([1, 2]) // [1, 2] or [[1, 2]]?
>
>
> I think it would be less painful a change (i.e. can be delayed past Swift
> 3) if we just augment what we have (the `...` argument declaration syntax)
> with a way to expand an Array in place of a variadic argument:
>
> func printThem(_ values: Any...)
>
> printThem(1) // values == [1]
> printThem([1]) // values == [[1]]
> // Possible expansion postfix syntax:
> printThem([1]...) // values == [1]
> // Expanding a non-array sequence:
> let things: Set = [1, 2, 3]
> printThem(Array(things)...)
>
>
> Good point, but actually these don't seem mutually exclusive; the three
> problem examples you gave could be resolved either by requiring the extra
> set of square brackets for clarity, and/or some kind of expansion like you
> suggest, either an operator or even possibly repurposing the attribute at
> the call-site for consistency. For example:
>
> printThem([1]) // warning, ambiguous
> printThem([[1]])// non-variadic
> printThem(@variadic [1]) // absolutely definitely 100% a variadic call
> printThem([1],) // alternative to an operator/attribute for
> variadic disambiguation?
>
> Thoughts?
>
>
> On 8 Jul 2016, at 10:42, Tino Heth <2...@gmx.de
> > wrote:
> I'm not sure if the timing of this proposal is coincidence (I recently
> revived a discussion to remove variadics)
>
>
> It is definitely not a coincidence ;)
> I participated in the discussion on removal in the past and actually
> posted a preliminary version of this there, so the recent posts reminded me
> to put it into a proper proposal. Personally like some I'd just remove the
> feature completely, but it seems enough people want to keep it that it's
> worth exploring alternatives as there seems a fairly even mix of those for
> and against the feature.
>


-- 
L
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Variadics as Attribute

[Leonardo Pessoa via swift-evolution]

I believe the alternative can be even simpler if you consider the type
of the variadic argument is in fact an array. The different syntax
tell the compiler it can relax on demanding an array for that argument
and allow multiple comma-separated values of the same declared type.
Nothing but the compiler complains if you try and pass an array there,
so the compiler could simply be updated to allow a list of arguments
or an array. Also, the compiler knows the type of the variadic
argument and the argument(s) you're passing so if you have 'Int...' it
should be able to recognise a [Int] as a valid (ans single) value.

One other alternative (or complement) is to use ar simple syntax to
tell the compiler you want to use the values of an array. In Ruby the
equivalent of our "args : String..." is simply "*args" (no types in
Ruby) and I can use the array or pass it as a variadic argument to
another function by passing "*args" instead of simply "args". It may
not be much nice visually but one could be able to use something like
"args..." here (I'm open to other suggestions, of course) just to
explicit/ensure that is what you want to do.

IMHO there is nothing that could be gained here with the change in
syntax (perhaps only a clarification that a variadic argument is an
array of that type for someone new to the language, but that's still
more verbose). Even if we were to change the syntax it would still
require changes on how the compiler perceives the arguments passed to
a function and I think we'd have less effort (and less breaking more
backward compatibility) if we just allow variadic arguments to receive
arrays of its type directly.

L


On 7 July 2016 at 18:15, Haravikk via swift-evolution
 wrote:
> Posted a new proposal, feedback appreciated:
>
> https://github.com/Haravikk/swift-evolution/blob/2743411af02e3ac6761fbdd780ede1af4cc34ee7/proposals/-variadics-as-attribute.md
>
> One talking point raised already is the correct location for the attribute
> (parameter or type); I'm undecided personally as there are arguments for
> both, probably not an important detail though (core team can make a decision
> on that I think), since the guidelines on attributes have been debated a few
> times already.
>
> Also, no matter how much I use it I seem to be the worst at using the Github
> website, so apologies for my many mistakes on that side of things ;)
>
> Variadics as Attribute
>
> Proposal: SE-
> Author: Haravikk
> Status: Awaiting review
> Review manager: TBD
>
> Introduction
>
> This proposal is for a redesign of the variadic function parameter syntax as
> an attribute for greater flexibility.
>
> Motivation
>
> Currently Swift variadic functions cannot be called with an array of values,
> potentially requiring two declarations like so:
>
> func someMethod(_ values:C) {
> … } // Regular method
> func someMethod(_ values:Int...) { someMethod(values) } // Variadic method
>
> In some cases this leads to only one being defined, forcing developers to
> use that particular style. When this is the variadic option this means the
> method is restricted in how it can be used, and parameters constructed.
>
> Proposed solution
>
> This proposal is to replace the current form of variadic declaration syntax
> (trailing elipsis) with a new attribute @variadicthat enables any suitable
> iterable parameter to be called in variadic form if desired.
>
> Detailed design
>
> Quite simply, instead of a trailing elipsis, a variadic parameter will
> instead be defined via a new @variadic attribute which can be placed upon
> any function parameter with a type conforming to ArrayLiteralConvertible, or
> which is a generic constraint against IteratorProtocol, Sequence or
> Collection such that a default (such as Array) can be used to fulfil the
> variadic call. Otherwise variadic parameters can be specified with the same
> restrictions they have now (must not be ambiguous).
>
> For example, consider the following variadic function:
>
> func someMethod(_ values:Int...) { … }
>
> Under this proposal the above can be rewritten as one of the following:
>
> func someMethod(@variadic _ values:[Int]) { … } // Basic Array solution
> func someMethod(@variadic _ values:Foo) { … }   // Foo is a custom
> ArrayLiteralConvertible type
> func someMethod(@variadic _
> values:I) { … } // Flexible, single-pass, generic solution
> func someMethod(@variadic _
> values:S) { … } // Flexible, (probably) multi-pass, generic solution
> func someMethod(@variadic _
> values:C) { … } // Flexible, definitely multi-pass, indexed, generic
> solution
>
> In this case the Iterator variation is preferred for greatest flexibility,
> but it will depend upon the actual requirements of the method. Any of these
> can be called as follows:
>
> someMethod([1, 2, 3, 4, 5, 6])  // normal array-literal call for any of the
> above
> someMethod(1, 2, 3, 4, 5, 6)// variadic call, synonymous with
> array-literal call
> someMethod(foo) 

Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

[Leonardo Pessoa via swift-evolution]

Goffredo, sorry if it felt offensive. It was not my intention. I've dealt with 
so many different libraries where, as many already pointed out here, has to 
rely on "fixing" the library themselves. This is not what a library was 
supposed to be and I might have left a few of my bad experiences speak louder.

L

-Original Message-
From: "Goffredo Marocchi" <pana...@gmail.com>
Sent: ‎07/‎07/‎2016 01:39 PM
To: "Leonardo Pessoa" <m...@lmpessoa.com>
Cc: "Jean-Daniel Dupas" <mail...@xenonium.com>; "swift-evolution" 
<swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Review] SE-0117: Default classes to 
benon-subclassable publicly

I disagree that a stable for over 30 years of every OOP language that I know is 
equivalent to lack of care for good library design, but if we want to push 
value types by making working with classes harder so be it :P. 


Seriously though


Mine is the opinion of a library-maker,
yours of the user of poorly designed/developed libraries.


this kind of attitude on this list got to stop.

Sent from my iPhone

On 7 Jul 2016, at 17:23, Leonardo Pessoa via swift-evolution 
<swift-evolution@swift.org> wrote:


Jean, IMO marking every class as subclassable means the creator does
not care for you to design and develop a great library because s/he is
not caring for the library at all. I right now have to go through the
burdensome activity of marking too many classes/methods as final to
prevent misuse of my libraries and find good design workarounds when I
need to subclass internally what I don't want you to subclass.

IMO the usage of a library is to be crafted/planned/designed by their
developers not their users. Mine is the opinion of a library-maker,
yours of the user of poorly designed/developed libraries. By pushing
this proposal, developer of such libraries will have much burden to
make/keep a poor library or will have to work on better
design/implementation for it to suit its purpose.

L

On 7 July 2016 at 13:08, Jean-Daniel Dupas via swift-evolution
<swift-evolution@swift.org> wrote:

* What is your evaluation of the proposal?



Strong -1 too.



I can’t count the number of times it save my hours tone able to override

arbitrary classes and methods.



Sometimes to simply add log point to understand how the API work. Other

times to workaround bugs in the library. Or even to extends the library in a

way that the author did not intent in the first place, but that was

perfectly supported anyway.



I already see how libraries author will react to that new default. They will

either don’t care and mark all classes as subclassable, or find to

burdensome to get subclassability right and prohibit subclassing all

classes.





Le 7 juil. 2016 à 02:27, Jonathan Hull via swift-evolution

<swift-evolution@swift.org> a écrit :



* What is your evaluation of the proposal?



A **strong** -1



First, I have often found that you can’t always predict the way which

something will need to be extended.  You think you know, but are then

surprised by creative uses.  My favorite features of Swift/Cocoa involve

retroactive modeling.



Second, I don’t think this proposal will achieve its stated objective of

forcing people to think about subclassing more.  It will just add confusing

boilerplate.



Things like Swift optionals work well because they make the (often

forgotten) choices explicit in the context that they are used.  In the world

of Human Factors, we call it a forcing function.  This proposal has the

inverse structure, and will be ineffective, because the “forcing” part of it

shows up in a different context (i.e. trying to use a framework) than the

decision is being made in (writing the framework).  This type of thinking

leads to things like Java and the DMV.



As Tino said:



No matter what the defaults are, good libraries are hard to build, so I

predict this proposal would not only fail in increasing framework quality,

but also will make it much harder for users of those frameworks to work

around their flaws, which are just a natural part of every software.



I think he is right on here.  Those who were prone to be thoughtful about

their design would have been anyway.  Those who are not thoughtful about

their design will just leave these annotations off… leaving us with no

recourse to extend/modify classes.  When people complain, they will add the

annotations without actually thinking about the meaning (i.e. stack overflow

/ the fixit tells me I need to add this word to make the compiler happy).

All this does is put framework users at the mercy of the framework writers.





Finally, this proposal is missing important aspects of the problem space.

If we truly want to solve the issue of subclassing, we need to consider all

of the common issues which arise.  Looking at the cocoa documentation you

will see several types of annotations:

1) This method M

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

Jean, IMO marking every class as subclassable means the creator does
not care for you to design and develop a great library because s/he is
not caring for the library at all. I right now have to go through the
burdensome activity of marking too many classes/methods as final to
prevent misuse of my libraries and find good design workarounds when I
need to subclass internally what I don't want you to subclass.

IMO the usage of a library is to be crafted/planned/designed by their
developers not their users. Mine is the opinion of a library-maker,
yours of the user of poorly designed/developed libraries. By pushing
this proposal, developer of such libraries will have much burden to
make/keep a poor library or will have to work on better
design/implementation for it to suit its purpose.

L

On 7 July 2016 at 13:08, Jean-Daniel Dupas via swift-evolution
 wrote:
>  * What is your evaluation of the proposal?
>
> Strong -1 too.
>
> I can’t count the number of times it save my hours tone able to override
> arbitrary classes and methods.
>
> Sometimes to simply add log point to understand how the API work. Other
> times to workaround bugs in the library. Or even to extends the library in a
> way that the author did not intent in the first place, but that was
> perfectly supported anyway.
>
> I already see how libraries author will react to that new default. They will
> either don’t care and mark all classes as subclassable, or find to
> burdensome to get subclassability right and prohibit subclassing all
> classes.
>
>
> Le 7 juil. 2016 à 02:27, Jonathan Hull via swift-evolution
>  a écrit :
>
> * What is your evaluation of the proposal?
>
> A **strong** -1
>
> First, I have often found that you can’t always predict the way which
> something will need to be extended.  You think you know, but are then
> surprised by creative uses.  My favorite features of Swift/Cocoa involve
> retroactive modeling.
>
> Second, I don’t think this proposal will achieve its stated objective of
> forcing people to think about subclassing more.  It will just add confusing
> boilerplate.
>
> Things like Swift optionals work well because they make the (often
> forgotten) choices explicit in the context that they are used.  In the world
> of Human Factors, we call it a forcing function.  This proposal has the
> inverse structure, and will be ineffective, because the “forcing” part of it
> shows up in a different context (i.e. trying to use a framework) than the
> decision is being made in (writing the framework).  This type of thinking
> leads to things like Java and the DMV.
>
> As Tino said:
>
> No matter what the defaults are, good libraries are hard to build, so I
> predict this proposal would not only fail in increasing framework quality,
> but also will make it much harder for users of those frameworks to work
> around their flaws, which are just a natural part of every software.
>
> I think he is right on here.  Those who were prone to be thoughtful about
> their design would have been anyway.  Those who are not thoughtful about
> their design will just leave these annotations off… leaving us with no
> recourse to extend/modify classes.  When people complain, they will add the
> annotations without actually thinking about the meaning (i.e. stack overflow
> / the fixit tells me I need to add this word to make the compiler happy).
> All this does is put framework users at the mercy of the framework writers.
>
>
> Finally, this proposal is missing important aspects of the problem space.
> If we truly want to solve the issue of subclassing, we need to consider all
> of the common issues which arise.  Looking at the cocoa documentation you
> will see several types of annotations:
> 1) This method MUST be overridden
> 2) This method should NOT be overridden
> 3) This method MUST be called
> 3) This method should NOT be called except by subclasses
> 4) This method should NOT be called except by a method override calling
> super
> 5) This method MUST call super
> 6) Overrides of this method should NOT call super
>
> If we are attempting to bring thoughtfulness to the design of classes, I
> would like to see things be extendable by default, but with annotations that
> thoughtful framework designers can use to designate how a particular method
> should be used.  In most cases, it should not explicitly forbid the end user
> from subclassing, but require them to acknowledge that what they are doing
> is not intended by the framework. (e.g. "unsafe override func"…).  That
> would feel 1000x more swifty to me.  Opt-out safety.
>
> * Is the problem being addressed significant enough to warrant a change to
> Swift?
>
> No. It doesn’t actually solve the problem... and I haven’t actually run into
> this problem in the real world.
>
> * Does this proposal fit well with the feel and direction of Swift?
>
> No, it gives Swift more of a feeling of busywork and unnecessary boilerplate
> while failing to 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

I don't disagree with you on 'fileprivate' and 'private' being
unnecessary and we may stick to the proposal at hand and leave the
'final' issue to another proposal, should anyone else care (I myself
don't mind if it sticks around - just have to not use it).

As for the conflict, I don't see it. Can you declare a 'public private
class'? I think it is just the same with 'open' and 'final'. And there
is no need to introduce an error for being redundant with 'public
final' either.

L

On 6 July 2016 at 18:36, Scott James Remnant  wrote:
>
> On Jul 6, 2016, at 2:13 PM, Leonardo Pessoa  wrote:
>
> You can also try and simplify your outlines reducing X.c and X.d to a
> single entry as it is the same rule applied to two different elements
> of the language. Using one single keyword (such as in 'open') would
> make it clearer and that is why I prefer to have only one keyword.
>
>
> I didn’t simply the outlines precisely because the proposal suggests two
> keywords.
>
> One keyword does solve this problem, but not the problem of conflation of
> finality and access control.
> You end up with this matrix:
>
>   access  | can override | final
>  -+--+---
>   open| yes  | Error - “class cannot be open and final"
>   public  | no   | Error - “public class is already final by
> default"
>   internal| yes  | final
>   fileprivate | yes  | final
>   private | yes  | final
>
> This is way more confusing than the current language:
>
>   access  | can override | final
>  -+--+---
>   public  | yes  | final
>   internal| yes  | final
>   fileprivate | yes  | final
>   private | yes  | final
>
> I strongly favor a programming language that doesn’t introduce compiler
> errors to solve problems that could be solved by cleaner syntax.
>
> Since it’s already necessary to place the `public` keyword in front of every
> class, method, property, or subscript that you intend to make public, the
> developer is already thinking about the public API. Typing `public final`
> instead of `public` is an extra keyword, it’s not an extra cognitive burden
> since that cognition is already taking place.
>
> Scott
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

So I did get what you meant right. Now tell me: if a class or method
is internal to your module (and you know internal means only you,
throught your source code, inside your app or library can extend it),
do you really need to mark anything as final for any reason? Final on
any non-publics is a restriction you put on yourself, you will always
have the power to lift that at any time (as long as you still own the
code, of course) so you are always in control of your subclasses and
overrides. All the time. It's up to you to subclass/override or not.
This is different from what you make public: you either have no
control or you have to fine grain control making everything final. You
regain that control over your publics with this proposal.

You can also try and simplify your outlines reducing X.c and X.d to a
single entry as it is the same rule applied to two different elements
of the language. Using one single keyword (such as in 'open') would
make it clearer and that is why I prefer to have only one keyword.

So, AFAICS, number 3 is how it should be with this proposal. As for
keeping the final keyword (sticking with number 2), I think it is up
to the community. I myself don't see any reason/need for it should
this proposal pass.

L

On 6 July 2016 at 17:32, Scott James Remnant  wrote:
>>
>> On Jul 6, 2016, at 1:16 PM, Leonardo Pessoa  wrote:
>>
>> Scott, I think your writing got a bit confuse but, if I got your
>> intention right, since you are the owner of the class, you may choose
>> to subclass it or not internally, no questions asked.
>
> No.
>
> This is how the language exists today:
>
> 1a. Default access control is `internal`, and may be modified by adding the 
> `public`, `fileprivate`, or `private` keyword, as appropriate.
>
> 1b. All classes may be subclassed, and all methods, properties, and 
> subscripts overridden. This can be prevented by adding the `final` keyword.
>
> The two concepts are very separate, and I think this is a good thing.
>
>
> What this proposal suggests, whether or not `final` is kept or removed, is 
> that the two concepts become conflated:
>
> 2a. Default access control is `internal`, and may be modified by adding the 
> `public`, `fileprivate`, or `private` keyword, as appropriate.
>
> 2b. Non-`public` classes may be subclassed, and non-`public` methods, 
> properties, and subscripts overridden. This can be prevented by adding the 
> `final` keyword.
>
> 2c. `public` classes may not be subclassed. To allow this replace the 
> `public` keyword with `subclassable`
>
> 2d. `public` methods, properties, and subscripts may not be overridden. To 
> allow this replace the `public` keyword with `overiddable`.
>
>
> Removing the `final` keyword means a change to 2b above. The first option is 
> simply to throw it away, in which case you end up with:
>
> 3a. Default access control is `internal`, and may be modified by adding the 
> `public`, `fileprivate`, or `private` keyword, as appropriate.
>
> 3b. Non-`public` classes may be subclassed, and non-`public` methods, 
> properties, and subscripts overridden. This can be never be prevented.
>
> 3c. `public` classes may not be subclassed. To allow this replace the 
> `public` keyword with `subclassable`
>
> 3d. `public` methods, properties, and subscripts may not be overridden. To 
> allow this replace the `public` keyword with `overiddable`.
>
>
> The second option is to throw it away, and adjust the default behavior so it 
> truly is `final` as removing the keyword would imply. Then you end up with:
>
> 4a. Default access control is `internal`, and may be modified by adding the 
> `public`, `fileprivate`, or `private` keyword, as appropriate.
>
> 4b. Non-`public` classes may not be subclassed, and non-`public` methods, 
> properties, and subscripts may not be overridden. This can never be allowed.
>
> 4c. `public` classes may not be subclassed. To allow this replace the 
> `public` keyword with `subclassable`
>
> 4d. `public` methods, properties, and subscripts may not be overridden. To 
> allow this replace the `public` keyword with `overiddable`.
>
>
> To me all of these options take a clean, easy-to-understand, language design 
> (1) and turn it into various states of mess. Removing the `final` keyword not 
> only makes it a mess, but removes functionality—the ability to have a mix of 
> final and non-final classes, methods, properties, and subscripts, accessible 
> only within your own module.
>
> Scott
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

Scott, I think your writing got a bit confuse but, if I got your
intention right, since you are the owner of the class, you may choose
to subclass it or not internally, no questions asked. I need no finals
in my apps and I only subclass if I intend to. If you are in control
of your own code, why would you need to ensure there would be no
subclassing/overriding? I'm not opposed to keeping the keyword if it
is important to anyone to be sure of that for internals. As for what
is public you will gain better control of what other people do to your
classes and methods.

L

On 6 July 2016 at 16:56, Scott James Remnant  wrote:
>
>> On Jul 6, 2016, at 12:50 PM, Leonardo Pessoa  wrote:
>>
>> Scott, you really got a point here: should this proposal pass, I
>> believe the final keyword should be removed as it would be already the
>> default behaviour and thus unnecessary. I don't think this is on the
>> proposal.
>>
>
> Removing the `final` keyword would mean there would be no way to have a class 
> of `internal` (default) scope that subclasses and another class of `internal` 
> (default) scope and overrides a method of `internal` (default) scope.
>
> Scott
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

Scott, you really got a point here: should this proposal pass, I
believe the final keyword should be removed as it would be already the
default behaviour and thus unnecessary. I don't think this is on the
proposal.

L

On 6 July 2016 at 16:47, Scott James Remnant via swift-evolution
 wrote:
> -1
>
> This proposal makes Swift a more confusing language.
>
>
> Swift already has a mechanism for creating public subclassable classes and
> non-subclassable classes:
>
>   public class SubclassableParentClass { }
>
>   public final class NonSubclassableParentClass { }
>
> This mechanism also applies to methods, properties, and subscripts:
>
>   public func bar() {}
>
>   public final func foo() {}
>
> The proposal makes no effort to remove this existing syntax.
>
> The very fact that this would be legitimate syntax as a result is a bad omen
> to me:
>
>   subclassable final class ConfusedParentClass {
>
> overridable final func quuz() {}
>
>   }
>
> The proposal doesn’t even address what that would do, the obvious answer is
> “compiler error,” but a better answer would be a language design that didn’t
> allow for this kind of ambiguity.
>
>
> Conflating access control and finality is confusing. The proposal actually
> even goes as far to argue that—“conflates” is a word I took from the
> proposal—but it’s solution *is* a conflation in of its right, because the
> only way to explain the results is in terms of both:
>
> classes, methods, properties, and subscripts with access control of
> `internal`, `file private`, and `private` are overridable by code that can
> access them, to prevent this add the `final` keyword.
> classes with access control of `public` are not overridable by code that can
> access them, to allow this replace the `public` keyword with the
> `subclassable` keyword.
> methods, properties, and subscripts with access control of `public` are not
> overridable by code that can access them, to allow this replace the `public`
> keyword with the `overridable` keyword.
>
>
> Not only is this complicated, and confusing, it isn’t even consistent: to
> deny overriding or subclassing you add the same keyword; but to allow
> overriding or subclassing you replace one keyword with two different ones,
> depending on which you’re doing.
>
>
> I agree that the alternative of flipping the default, and replacing `final`
> with `nonfinal` is also undesirable. One of the nicer features of the Swift
> language design is that the language is easiest for app developers working
> within a single module, where it can be assumed that “everyone is an adult.”
> Breaking this to support the less common case of Public API Designers would
> be a step backwards; their case is important, but it shouldn’t come at a
> penalty.
>
> Scott
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

Intention.

IMO, intention may lead to more secure systems (and libraries). By
having to explicitly final everything I have to choose with parts of
my class/library would be locked and have to worry and check if any
public thing could be used to exploit it or make the system work in a
way I did not intended to. Also, final will prevent anyone including
me from extending/overriding. Defaulting to final would require from
me to explicitly declare the open endpoints in my libraries, so I
could explicitly open only the ones that are really intended to be
used in that way by third-parties.

As an example, I'm working on a system which has an internal
representation of Files and Folders using a common superclass (lets
call it Entry). I would like for other developers to be able to create
new entry types (not only inheriting from File) but I do not wish for
them to extend from Folder or any of its subclasses (specialised
folders). By using final I can prevent others from extending my Folder
but I cannot extend it myself and thus need another mechanism for
achieving this behaviour without bloating the Folder class with all
its specialisations. This proposal would allow me to make my Folder
and its subclasses publicly available/usable but would prevent others
from subclassing and thus misusing them in ways I did not intend them
to. The same rationale applies to methods.

L

On 6 July 2016 at 16:09, Goffredo Marocchi <pana...@gmail.com> wrote:
> Leonardo, how is defaulting to final/sealed helping you write better 
> libraries than having a final keyword for what you need to close instead?
>
> Sent from my iPhone
>
> On 6 Jul 2016, at 16:48, Leonardo Pessoa via swift-evolution 
> <swift-evolution@swift.org> wrote:
>
>>> The review of "SE-0117: Default classes to be non-subclassable publicly" 
>>> begins now and runs through July 11. The proposal is available here:
>>>
>>>
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
>>>
>>>* What is your evaluation of the proposal?
>>
>> +1. Being able to control how a class from my libraries are going to
>> be used by third-parties could enable a better designed API with more
>> control of how it is intended to be used. I'm just not fond of using
>> the proposed keywords ('subclassable' and 'overridable') as they feel
>> more like protocol or attribute names; I'd be more inclined to use the
>> alternative 'public open' instead, or 'public(open)' as a second
>> option.
>>
>>>* Is the problem being addressed significant enough to warrant a 
>>> change to Swift?
>>
>> I'd say it is significant to every language.
>>
>>>* Does this proposal fit well with the feel and direction of Swift?
>>
>> Yes.
>>
>>>* If you have used other languages or libraries with a similar 
>>> feature, how do you feel that this proposal compares to those?
>>
>> C# uses the keyword 'virtual' to explicitly mark methods that can be
>> overriden (not considered in the alternatives but I'm not a big fan of
>> it).
>>
>>>* How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>>
>> I've took (a small) part on the thread discussing this proposal but
>> followed it closely
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Removing Variadic Parameters.

[Leonardo Pessoa via swift-evolution]

-1_000_000_000

I believe variadic parameters are useful in a range of situations and
I use them myself a lot. As you mentioned yourself, you never created
variadic functions and you are allowed to continue working like that
for as long as it suits you so. It is a choice and you and other
developers are allowed to decide when and where to use it. As for
trailing closures, just as Saagar mentioned, your variadic parameter
does not have to be the last one, as it has to in C, and thus they do
not compete. Give it a try.

L

On 6 July 2016 at 15:49, Saagar Jha via swift-evolution
 wrote:
>
>
> On Wed, Jul 6, 2016 at 11:38 AM Tino Heth via swift-evolution
>  wrote:
>>
>> It's a late answer… but I wanted to be a good citizen and checked if the
>> topic has been discussed before; so, it seems that is not the case ;-)
>>
>> In short, I agree:
>> Variadic parameters are somewhat cool, and I think I was exited when I've
>> seen them in C the first time… but I afair, I never created a variadic
>> function in production code, and I think I just used them for the first time
>> in Swift (I checked wether print is variadic…)
>> As of today, string interpolation has several advantages over old-style
>> string-formatting, and I can't remember any other method in one of the
>> established libraries that uses this feature:
>> Explicitly creating an array is just two additional characters, which
>> doesn't matter in a long list (which imho shouldn't be crammed into the
>> function call anyways), and when there are only a few parameters, you can
>> mimic variadics with Optionals defaulted to nil — and who knows what the
>> long-awaited hygienic macros might do to the importance of variadic
>> parameters.
>>
>> Additionally, variadic parameters compete with trailing closures, which
>> for me would always win the struggle for the last parameter ;-)
>
>
> Actually, you don’t have to make a variadic parameter last…print doesn’t.
>
>>
>>
>> As I said, I can't remember a single use case in Swift — and I already
>> utilized quite a lot of the "strange" techniques (currying, tuple splat,
>> complicated combinations of generics & protocols…).
>> So for me, the answer to the question "would I add this feature to Swift
>> if it wasn't there?" is a clear no…
>>
>> Tino
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> --
> -Saagar Jha
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa via swift-evolution]

> The review of "SE-0117: Default classes to be non-subclassable publicly" 
> begins now and runs through July 11. The proposal is available here:
>
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
>
> * What is your evaluation of the proposal?

+1. Being able to control how a class from my libraries are going to
be used by third-parties could enable a better designed API with more
control of how it is intended to be used. I'm just not fond of using
the proposed keywords ('subclassable' and 'overridable') as they feel
more like protocol or attribute names; I'd be more inclined to use the
alternative 'public open' instead, or 'public(open)' as a second
option.

> * Is the problem being addressed significant enough to warrant a 
> change to Swift?

I'd say it is significant to every language.

> * Does this proposal fit well with the feel and direction of Swift?

Yes.

> * If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

C# uses the keyword 'virtual' to explicitly mark methods that can be
overriden (not considered in the alternatives but I'm not a big fan of
it).

> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

I've took (a small) part on the thread discussing this proposal but
followed it closely
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

[Leonardo Pessoa via swift-evolution]

And it is something the compiler can check whether it is necessary for
your code or not based on some simple and easy pattern. If it is so
simple, why not let the compiler handle it?

On 4 July 2016 at 16:02, Vladimir.S via swift-evolution
 wrote:
> On 04.07.2016 21:21, Brent Royal-Gordon via swift-evolution wrote:
>>>
>>> On Jul 4, 2016, at 10:43 AM, Leonardo Pessoa  wrote:
>>>
>>> My issue with this being opt-in is third-party libraries.
>>
>>
>> That's why we have retroactive modeling. :^)
>>
>> import SomeEnumKit
>> extension SomeEnum: ValuesEnumerable {}
>>
>> You can extend another module's public enum to add conformance to a
>> protocol, and there's no reason it can't generate the code in your module
>> instead of theirs.
>>
>
> Yes, but I can't understand, why not give this ability to each enum? It
> seems like this feature is a very basic thing that enum must(IMO) to have.
> What kind of overhead this will generate? Static function or property that
> returns array as I understand should not generate any impact on memory
> required to store each separate *instance* of enum. I don't believe that
> adding a number of bytes to enum *type* to implement .allValues(or whatever
> named) will have any difference for total application/framework.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

[Leonardo Pessoa via swift-evolution]

My issue with this being opt-in is third-party libraries. The
developer of a library may not have intended or thought of a use for
the enum this way but some other developer might have. Being opt-in
would prevent such scenarios from easily happening or require the
developer to (again) manually implement the feature. Also, it should
be possible to opmise the compiler so it dynamically generates or
suppresses the property as needed by an app as the compiler has to
know all the values possible (or it could not demand us to write
exaustive switches).

L

On 4 July 2016 at 04:14, Brent Royal-Gordon via swift-evolution
 wrote:
>> On Jul 3, 2016, at 6:36 PM, Gabriel Lanata via swift-evolution 
>>  wrote:
>>
>> Hello, this has been proposed multiple times before in different ways.
>
> It has indeed. Unfortunately, for various reasons it did not get into review 
> in time, and Swift 3 is basically closed to additive features at this point. 
> Our last pull request to get it reviewed has now been tagged "out of scope 
> for current release". 
>
>> The proposed solution is to implement a native `.cases` static var for all 
>> enumerations without associated values.
>
>
> That was one of many things we discussed in previous threads. `cases` isn't 
> good because the natural variable you'd want to use in a `for` loop is `case`:
>
> for case in PokemonType.cases { … }
>
> And also because other types which aren't technically enums, such as `Bool`, 
> may want to expose their "cases" through the same mechanism.
>
> From the proposal:
>
>> The resulting areay of cases are ordered in the way they appear in the 
>> source code.
>
>
> Here's one of the sticking points: Should this actually be an array, or 
> should it be some other kind of collection? An array takes up space to store 
> its elements, and for many enums there's no actual reason it needs to. Using 
> a custom collection instead could save memory.
>
>> I believe this behaviour should be natively available to all enums. There is 
>> no reason to require that enums conform to the protocol if this behaviour 
>> could be used in all of them.
>
> In previous discussions, the core team specifically asked that this be opt-in 
> so that types which don't want it don't need to "pay" for it.
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

[Leonardo Pessoa via swift-evolution]

That is actually something I argued over this list with other users
and (at least when I proposed) was not very well accepted. This
certainly has my +1.

On 4 July 2016 at 02:52, Gabriel Lanata via swift-evolution
 wrote:
> I know! I am amazed this hasn’t had a formal proposal and review yet. I did
> a search through the mailing list and found that it has been mentioned many
> times before (these mentions are linked in the proposal) but it has never
> gone into review. The other posts proposed slightly different solutions
> which were not as intuitive, the solution I’m proposing is the simplest and
> most useful way it can be implemented.
>
> ---
> Gabriel
>
>
> On Jul 4, 2016, 12:47 AM -0500, Tino Heth <2...@gmx.de>, wrote:
>
> Hi there,
>
> right now, I have 7115 unread messages in my Swift-folder, so I'm surprised
> that there hasn't already been a successful proposal to add this feature…
> afaiks, it wouldn't hurt anybody, and many people want to have it.
>
> Therefore:
> +1, and good luck! ;-)
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Sealed classes by default

[Leonardo Pessoa via swift-evolution]

The proposal was to use "sealed" so why not "opened"? I understand it
may not be common to use "opened" as an adjective but from the
dictionaries I consulted it is possible to.

opened class MyViewController: UIViewController {
   opened func displayMe(_ me: person) { … }
}

On 1 July 2016 at 13:47, John McCall via swift-evolution
 wrote:
> On Jul 1, 2016, at 12:23 AM, Xiaodi Wu  wrote:
> That starts to look an awful lot like a fifth access level just for classes
> (I know you're not proposing one, but it could start to look that way to a
> user). I think there's much to be said for having the word public in front
> of things that are public. Unless, of course, your strawman keyword is a
> much maligned compound word that begins with "public", like
> "publicoverridable".
>
>
> I would also prefer a single keyword if the word implies something about
> accessibility.  "open" does that, although using it here would conflict with
> its potential use on enums unless we required all cases within the defining
> module to be present in the enum declaration rather than extensions.
>
> I don't think we'd ever use a compound keyword that starts with public; we'd
> just separate them and say that the second half can only be present on a
> public declaration, or do this parenthesized syntax.
>
> John.
>
>
> On Fri, Jul 1, 2016 at 01:54 Brent Royal-Gordon 
> wrote:
>>
>> > If we're going to go along those lines, we should just use
>> > public(subclassable) and public(overridable).  We can fall back on those if
>> > necessary; I would just like to continue looking for better alternatives.
>>
>> I would prefer to have a *single* keyword which meant both public and
>> overridable. That would minimize the impact of this feature—instead of
>> writing:
>>
>> public class MyViewController: UIViewController {
>> public func displayMe(_ me: person) { … }
>> }
>>
>> You'd write (strawman keyword):
>>
>> openseason class MyViewController: UIViewController {
>> openseason func displayMe(_ me: person) { … }
>> }
>>
>> And then `MyViewController` could be subclassed, and `displayMe`
>> overridden.
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Leonardo Pessoa via swift-evolution]

I'll stick with Gwynne here. Each language has its syntax for
interpolating string and as such I don't see a reason to change this.
As for formatting, I agree it is an issue but we have to remember that
inside \() we have code that can do pretty much everything one may
need. You may even add a formatting function to String or Int in order
to produce the result you need (even simplifying the calls to
NumberFormatter - I myself have a whole library of "shortcuts" I add
to every project).

L

On 21 June 2016 at 18:49, Gwynne Raskind via swift-evolution
 wrote:
> On Jun 21, 2016, at 15:48, Jonathan Cotton via swift-evolution
>  wrote:
>
> I'd support $() as is in use by other languages, including Kotlin, as
> mentioned it seems less disruptive and more inline with the tokenised
> parameters that are already supported in closures.
>
> On 21 Jun 2016, at 21:43, Kenny Wyland via swift-evolution
>  wrote:
>
> Hi all,
>
> I'm new to the list and I just searched through the archives as best I could
> to see if someone else had already brought this up, but I didn't find
> anything. Forgive me if this horse has been beaten.
>
> I find that typing \(var) is very disruptive to my typing flow. The more I
> code in Swift, the more I like it, but every time I'm coding and then have
> to hiccup while typing \ then ( causes me to be annoyed. I know, it's minor,
> but it isn't a key combination that flows quickly.
>
> I would much rather have $() or perhaps ${} (like Groovy lang) or perhaps
> @() to go along with other uses of @ throughout the language.
>
> A shifted key, like $ or @, followed by another shifted key like (, allows
> for a much faster flow and they are much closer to the home keys than \
> which is nearly as far from home keys as possible (and awkward).
>
> Thoughts?
>
> Kenny Wyland
> InADayDevelopment.com
>
>
> I have to disagree - The \ syntax is consistent with other string escape
> sequences (\n etc.) and reads naturally to me in that regard. Additionally,
> the \ is very visually distinctive in a string, much moreso than the
> "traditional" $ variable marker. Almost every language I’ve seen using $ for
> interpolation in strings is doing so because it also uses it as a variable
> prefix in non-string contexts. To top it off, using $ instead would, for me,
> just add yet another language for which I have to remember "does the $ go
> inside or outside the name delimiter braces/brackets/whatever?", "is it
> parenthesis, braces, brackets, or some other delimiter for variable names?",
> "what kind of expressions can I use in this context?", "can I use
> interpolation without any delimiters for simple cases?", etc. See also PHP,
> Perl, ten flavors of shell scripts, JavaScript, JSP/ASP, XPath, and so
> forth. The \() syntax is unique to Swift and therefore very easy to
> remember.
>
> I also don’t see that Swift carries an expectation of being able to use a
> syntax which is traditionally confined to interpreted/scripting languages,
> and even there $ is by no means ubiquitous. Here are just a few
> counterexamples among various languages:
>
> - C (printf formats)
> - C++ (stream modifiers)
> - Objective-C (NSString formats)
> - C# ($, but with the unusual syntax $"blah {foo} blah")
> - Lua (printf formats and language hacks)
> - Python (printf formats with trailing "% (tuple)" syntax)
> - Ruby ("#{}")
> - Java (printf formats)
>
> There’s an obvious pattern in these example, which brings to something I
> _would_ like to see for string interpolation in Swift: Better control over
> the precise representation of the data. I’m sure the topic has been done to
> death many times before, but I haven’t found any solid information at a
> quick search, so I apologize if this is all old hat.
>
> Anyway - Creating, configuring, and invoking various Formatter types in
> order to present data in the proper fashion is an option, and a preferable
> one when the data is intended for user consumption (especially to get the
> maximum support from localization). But for logging, debugging, parsing of
> textual formats, writing textual formats, etc., I almost always want a
> traditional C/POSIX/ISO representation as easily provided by printf()-style
> specifiers. 99% of the time when I want to do an number-to-string (integer
> or otherwise) conversion especially, I’m being specific about the appearance
> of the number.
>
> For example, for a hex representation of sockaddr_in.sin_addr.s_addr, I
> would in other languages write "printf("0x%08x", address.sin_addr.s_addr);",
> or "%02hhu" times four to get dotted-decimal notation. (Ignoring for the
> moment the existence of inet_ntop() for the sake of the example :). In
> Swift, I currently have to make a call to printf(), fprintf(), dprintf(),
> NSString(format:), asprintf() (with a wrapper to deal with getting a
> Swift.String from allocated memory), etc. A configured NumberFormatter
> instance is a 

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

[Leonardo Pessoa via swift-evolution]

On 21 June 2016 at 14:03, Chris Lattner via swift-evolution
 wrote:
> Hello Swift community,
>
> The review of "SE-0101: Rename sizeof and related functions to comply with 
> API Guidelines" begins now and runs through June 27. The proposal is 
> available here:
>
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md
>
> * What is your evaluation of the proposal?

After a carefull review of the proposal, I will be obligated to
decline it. After studying the proposal I ended up thinking I was
writing more code to get the data and in comparison with dynamicType
-> type(of:) it lead me to think at first the proposal would suggest
renaming size* functions to size(of*:) and so forth, which would seem
to go more towards the compared proposal (SE-0096). This idea doesn't
even made into the alternatives considered and I think it would making
reading and understanding the code much clearer than the proposed
nested function calls.

> * Is the problem being addressed significant enough to warrant a 
> change to Swift?

I'm not sure. Given the reasoning I'd say yes but given proposal
SE-0096 I'd say yes only if the new function names were to be
size(of*:), stride(of*:) and align(of*:) and thus not depending of the
nested result of type(of*:).

> * Does this proposal fit well with the feel and direction of Swift?

I don't think so. As I said, when I finished reading the proposal, I
ended up thinking I was writing more code in the new version and it
didn't seem very clear to me what was the size I was getting.
Moreover, it seems I'll always have to invoke these functions to the
result of type(of*:) which would be unnecessary redundant code.

> * If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

Many languages (like C/C++, C#, D) have both sizeof and typeof and in
most these two functions have similar names and syntaxes. In this case
I believe making them different makes it hard to discover those
functions exist and relate their purpose.

> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

A quick study was enough for me.

L
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] the "guard" keyword, again

[Leonardo Pessoa via swift-evolution]

Perhaps that was the original idea (guard as a multithreaded statement)
since in iOS your code and the UI run on different threads. Anyway, I'd
still stick with guard as I don't think this is confusing enough to justify
a change.

On Tuesday, 21 June 2016, James Campbell via swift-evolution <
swift-evolution@swift.org
> wrote:

> I think unless has always made more sense, guard felt like a multithreaded
> statement as in guard this variable from other threads.
>
> *___*
>
> *James⎥Head of Trolls*
>
> *ja...@supmenow.com⎥supmenow.com *
>
> *Sup*
>
> *Runway East *
>
> *10 Finsbury Square*
>
> *London*
>
> * EC2A 1AF *
>
> On 21 June 2016 at 09:14, Rimantas Liubertas via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> In summary, “require … else” is a very clean choice and beats “guard ...
>>> else” handily.
>>>
>>
>> For you maybe. I prefer quard—it carries slightly different semantic load
>> and fits more cases, imho.
>>
>> r.
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>

-- 
L
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need animpl

[Leonardo Pessoa via swift-evolution]

The thing with NSUnimplemented was really just a mention and nothing to do with 
the issue.

As for the real issue, the blacklist you mention is formed after parsing the 
source. That's how compilers usually work. The function impl is expected due to 
the syntax definition that is checked during the parsing phase and before that 
blacklist is formed. Thus one would have to flex the syntax and allow every 
func to not have a body and only after parsing the source check if the func had 
or not to have a body based on the unavailable attribute. That is unless the 
compiler analyses the source code while it's being parsed and I don't believe 
the Swift compiler does that (I haven't been that down the rabbit hole so I'm 
not affirming). Please note that in not saying it cannot be done, only that 
there may be consequences.

L

-Original Message-
From: "Austin Zheng" 
Sent: ‎10/‎06/‎2016 06:42 PM
To: "Leonardo Pessoa" 
Cc: "Erica Sadun" ; "swift-evolution" 

Subject: Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need 
animpl

NSUnimplemented() has nothing to do with the Swift compiler proper, and you 
won't find it in the Swift repo. It's a marker used for the Swift Foundation 
project to denote methods and APIs that haven't yet been implemented. It has 
nothing to do with availability/renamed.


As for the overhead, I don't understand this argument either. Today, the 
compiler already has to cross-check the use of an API against a list of whether 
or not it's been blacklisted using "unavailable". If it's "unavailable" the 
compiler stops with an error and does not need to further check whether a 
function body has been defined. As for the grammar, there are already 
productions defined for member declarations without implementations, used for 
constructing protocols.


Austin


On Fri, Jun 10, 2016 at 2:32 PM, Leonardo Pessoa  wrote:

I've seen around the Swift source code some uses of a function named
something like NSUnimplemented(). I'm not sure this is available only
inside the Swift source or if we could call it as well (I'm not in
front of a Swift compiler right now so I cannot test).

The idea of being able to drop the body of the function is interesting
but I keep thinking of the overhead of the compiler to check for every
function if it can drop the requirement for a body. Perhaps keeping
the body is well suited here.

On 10 June 2016 at 18:26, Erica Sadun via swift-evolution

 wrote:
> On Jun 10, 2016, at 3:22 PM, Austin Zheng via swift-evolution
>  wrote:
>
> So, instead of:
>
> @available(*, unavailable, renamed:"someNewAPI()")
> public func someOldAPI() -> Int { fatalError() }
>
> You can just have:
>
> @available(*, unavailable, renamed:"someNewAPI()")
> public func someOldAPI() -> Int
>
> The intent is, in my opinion, clearer for the latter and it feels less
> kludgy.
>
>
> You ask, we answer. I'd much prefer spelling out { fatalError("unavailable
> API") }.
> It makes the code clearer to read, to maintain, it produces debug and
> runtime errors. etc. I think
> this is an example where concision is overrated.
>
> -- E
>
>
>

> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

[Leonardo Pessoa via swift-evolution]

I've seen around the Swift source code some uses of a function named
something like NSUnimplemented(). I'm not sure this is available only
inside the Swift source or if we could call it as well (I'm not in
front of a Swift compiler right now so I cannot test).

The idea of being able to drop the body of the function is interesting
but I keep thinking of the overhead of the compiler to check for every
function if it can drop the requirement for a body. Perhaps keeping
the body is well suited here.

On 10 June 2016 at 18:26, Erica Sadun via swift-evolution
 wrote:
> On Jun 10, 2016, at 3:22 PM, Austin Zheng via swift-evolution
>  wrote:
>
> So, instead of:
>
> @available(*, unavailable, renamed:"someNewAPI()")
> public func someOldAPI() -> Int { fatalError() }
>
> You can just have:
>
> @available(*, unavailable, renamed:"someNewAPI()")
> public func someOldAPI() -> Int
>
> The intent is, in my opinion, clearer for the latter and it feels less
> kludgy.
>
>
> You ask, we answer. I'd much prefer spelling out { fatalError("unavailable
> API") }.
> It makes the code clearer to read, to maintain, it produces debug and
> runtime errors. etc. I think
> this is an example where concision is overrated.
>
> -- E
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

[Leonardo Pessoa via swift-evolution]

I would vow to remove where clauses altogether. Most of the times I used it in 
ifs, fors and switches I ended up thinking it hardened readability of my code 
(perhaps because of placement, but I do not think alternatives made it more 
readable) and so it was my decision to stop using where whenever possible in my 
code. Since Erica's performance test pointed out using guard is nearly as fast 
as using where and the core team is removing wheres from ifs, I think the ones 
in fors could go next.

L

> On 10 Jun 2016, at 2:01 am, Charlie Monroe via swift-evolution 
>  wrote:
> 
> 
>> On Jun 9, 2016, at 7:16 PM, Erica Sadun  wrote:
>> 
>> 
>>> On Jun 9, 2016, at 11:11 AM, Charlie Monroe  
>>> wrote:
>>> See my latest post - included results with -Ofast. But still, using filter 
>>> and lazy.filter is 10+% slower, which were the suggested alternatives to 
>>> `where`.
>> 
>> I need to correct this misapprehension.
>> My suggested alternative to where was and remains `guard`.
>> 
>> -- E
> 
> Sorry, meant alternatives that didn't require any additional code in the body 
> of the for loop.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Add conversion String -> Bool

[Leonardo Pessoa via swift-evolution]

I think it would be interesting if it could also recognise "1" and "yes" too as 
it can be useful in some cases. Perhaps have an option for this converter to be 
customised.

L

-Original Message-
From: "Arsen Gasparyan via swift-evolution" 
Sent: ‎04/‎06/‎2016 10:10 AM
To: "swift-evolution@swift.org" 
Subject: [swift-evolution] Add conversion String -> Bool

Hello,


It would be great if we had `init?(_ text: String)` for Bool class. Because 
sometime when you're processing JSON/XML it can help you a lot.


Examples:


Bool("true") -> true
Bool("false") -> false
Bool("TrUE") -> true
Bool(" true ") -> nil
Bool("1") -> nil
Bool("Y") -> nil
Bool("whatever") -> nil via https://bugs.swift.org/browse/SR-1282


Thanks.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

Patrick, I never said the order of the enum was intrinsic. If the offset of the 
case were the truth of the enum as you said enums would be ordinal types and 
you could do tests like "Planet.Mercury > Planet.Venus" without any extra code. 
But enums are nominal types not ordinal types so you can only distinguish the 
different values but they have no particular order or any other property. Two 
simple examples of nominal types are colours and cardinal points. Do they have 
any particular order? That's how enums are implemented in Swift (as a nominal 
type) and that's another reason why working with case names makes even more 
sense.

L

-Original Message-
From: "Patrick Smith" 
Sent: ‎02/‎06/‎2016 11:18 PM
To: "Leonardo Pessoa" 
Cc: "Brent Royal-Gordon" ; "swift-evolution" 

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

>From what I understand, enums normally are represented internally by an offset 
>— that is their truth. With RawRepresentable enums, you are saying “no, I want 
>the truth to be something else”. But it seems that they are still represented 
>internally by an offset, so you can’t reorder a RawRepresentable enum’s cases 
>and maintain ABI compatibility either.


So what you are saying about the order of cases being an intrinsic part of an 
enum does make sense. I’m not sure if can still lead to confusing / fragile 
code though.


Patrick




On 2 Jun 2016, at 10:17 PM, Leonardo Pessoa  wrote:


There are several ways to solve this, which IMO is a basic functionality of 
enums, writing code that is currently possible and works. But that's the issue, 
you still have to write code to have a basic functionally. I don't remember not 
being able to do this out-of-the-box in any language I worked with.

L


From: Patrick Smith
Sent: ‎02/‎06/‎2016 02:07 AM
To: Brent Royal-Gordon
Cc: Leonardo Pessoa; swift-evolution
Subject: Re: [swift-evolution] Working with enums by name


Great points Brent. I think the ValuesEnumerable method would be the most 
straight forward. Also, the number of cases are likely only going to be in 
range of 6–20, so iterating would be fine I think. People can create something 
like `Dictionary(Planet.allValues.enumerated().lazy.map{ ($1, $0) })` (I think 
that’s right) if they really need.


> On 2 Jun 2016, at 2:40 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> Or the `ValuesEnumerable` proposal would give you a convenient, though 
> slightly slow, way to do two-way lookup by order:
> 
> enum Planet: String, ValuesEnumerable {
> var order: Int {
> return Planet.allValues.index(of: self)!
> }
> init(order: Int) {
> self = Planet.allValues[order]
> }
> case mercury, venus, …
> }___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

There are several ways to solve this, which IMO is a basic functionality of 
enums, writing code that is currently possible and works. But that's the issue, 
you still have to write code to have a basic functionally. I don't remember not 
being able to do this out-of-the-box in any language I worked with.

L

-Original Message-
From: "Patrick Smith" 
Sent: ‎02/‎06/‎2016 02:07 AM
To: "Brent Royal-Gordon" 
Cc: "Leonardo Pessoa" ; "swift-evolution" 

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

Great points Brent. I think the ValuesEnumerable method would be the most 
straight forward. Also, the number of cases are likely only going to be in 
range of 6–20, so iterating would be fine I think. People can create something 
like `Dictionary(Planet.allValues.enumerated().lazy.map{ ($1, $0) })` (I think 
that’s right) if they really need.


> On 2 Jun 2016, at 2:40 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> Or the `ValuesEnumerable` proposal would give you a convenient, though 
> slightly slow, way to do two-way lookup by order:
> 
>   enum Planet: String, ValuesEnumerable {
>   var order: Int {
>   return Planet.allValues.index(of: self)!
>   }
>   init(order: Int) {
>   self = Planet.allValues[order]
>   }
>   case mercury, venus, …
>   }

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

I understand you don't like to rely on the name of your enum cases in you code 
and that's fine, you can still work with them as is, you won't have to change 
the way you work just because you don't like the proposal but that doesn't mean 
everybody has the same opinion you do. But perhaps then instead of enums we 
should go back to using simple constants because that's exactly what enum cases 
become if their names are not how you're expected to reference, store and 
retrieve their values (yes, I understand there are other benefits to using 
enums instead of constants but that's just how you're using them).

L

-Original Message-
From: "Brent Royal-Gordon" 
Sent: ‎02/‎06/‎2016 01:40 AM
To: "Leonardo Pessoa" 
Cc: "Vladimir.S" ; "swift-evolution" 

Subject: 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 was the one who suggested accessors.

> As for working with enum values by name a few examples have already been 
> posted in today but I've done a lot more research in the subject along the 
> day and found there is a correlation between enums and nominal level values 
> in statistics; we cannot test them for a particular order (this could also be 
> interesting for statistic apps but it's another case) and no math with them 
> is valid. So, e.g., the result of the following operation on the planets enum 
> is nonsense:
> 
> |   let planet = Planet(rawValue: Planet.Mars.rawValue - 
> Planet.Mercury.rawValue)
> 
> The result will be different if the enum values are zero based than if not. 
> Also any change in list order or the base index or add a new element to the 
> middle of the list will break your intended code if you're storing the raw 
> value in a database. And we know these changes happen.

All of this is true. And all of this is an argument that *you're using raw 
values wrong*.

Raw values are a serialization mechanism. You might be serializing merely 
within your process, or you might be writing out to disk, through IPC, or 
across the network, but in all cases you are serializing. You should not be 
doing arithmetic with a serialized representation (unless that arithmetic is a 
part of the serialization process, like an error-correcting code you're 
applying to it). You should not be sorting serialized representations. You 
should be either communicating the raw value or recreating the instance with 
it—nothing else.

In other words, all of these are arguments for putting the order of the Planet 
in a separate property rather than in the `rawValue`. This would free up the 
`rawValue` to be a `String` containing the case name. This is not an argument 
for having both an Int `rawValue` and a String `caseName`; this is an argument 
for having both a String `rawValue` and an Int property.

enum Planet: String {
accessor var order: Int

case mercury { order = 0 }
case venus { order = 1 }
...etc...
}

(Want it to be automatic? One could imagine having a compiler substitution for 
"the index of this case" which could be used as the default value for an 
accessor:

enum Planet: String {
accessor var order: Int = #caseIndex
case mercury, venus, ...
}

Or let you choose a base:

enum Planet: String {
accessor var order: Int = #caseOrder(from: 1)
case mercury, venus, ...
}

Or the `ValuesEnumerable` proposal would give you a convenient, though slightly 
slow, way to do two-way lookup by order:

enum Planet: String, ValuesEnumerable {
var order: Int {
return Planet.allValues.index(of: self)!
}
init(order: Int) {
self = Planet.allValues[order]
}
case mercury, venus, …
}

In short, there are several plausible mechanisms to automate assignment of 
these numbers, should you want to do that.)

> Actually, given this characteristic of nominal types (statistic), we should 
> vow to removing init(rawValue:) completely from the language.

That doesn't follow. The fact that changing something would break code doesn't 
mean that thing should be removed; it means you should be cautious about 
changing that thing. If you rename a case, its name changes; does that mean we 
shouldn't have case name lookups either? Changing any identifier could break 
something; maybe we should abolish all identifiers from Swift?

> The real value you're working with in enums is the enum case name not any 
> associated 

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

[Leonardo Pessoa via swift-evolution]

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 enum values by name a few examples have already been posted 
in today but I've done a lot more research in the subject along the day and 
found there is a correlation between enums and nominal level values in 
statistics; we cannot test them for a particular order (this could also be 
interesting for statistic apps but it's another case) and no math with them is 
valid. So, e.g., the result of the following operation on the planets enum is 
nonsense:

|   let planet = Planet(rawValue: Planet.Mars.rawValue - 
Planet.Mercury.rawValue)

The result will be different if the enum values are zero based than if not. 
Also any change in list order or the base index or add a new element to the 
middle of the list will break your intended code if you're storing the raw 
value in a database. And we know these changes happen. Actually, given this 
characteristic of nominal types (statistic), we should vow to removing 
init(rawValue:) completely from the language.

The real value you're working with in enums is the enum case name not any 
associated values. By working with the name you're safe should any associated 
value change, should their order change, you'll only break your app if the case 
is removed/renamed (with the raw value, you risk having the wrong treatment 
being given should another enum case takes the value of a removed one).

I agree there are lots of important and more difficult things to review in the 
language but I wouldn't be wasting my time here if I didn't think this was 
equally important.

L

-Original Message-
From: "Brent Royal-Gordon" 
Sent: ‎01/‎06/‎2016 06:10 PM
To: "Leonardo Pessoa" 
Cc: "Vladimir.S" ; "swift-evolution" 

Subject: 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? We have to decide which use cases are 
common enough to support directly in the language, and I'm not convinced that 
"I need to look cases up by name, but I have no choice but to use rawValue for 
something else" is one of them—that is, that it's *so* common that we need to 
direct our scarce engineering resources towards designing and implementing a 
separate feature merely to accommodate it. There are a whole lot of things that 
are *way* higher on our to-do list than this, arguably including 
metaprogramming features which would let you write this yourself instead of 
sticking it in the core language.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

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, Christopher Kornher via swift-evolution
 wrote:
>
> 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 is inside some other data structure that you get an annoyingly
> fully qualified name:
>
> enum CoinSide {
> case heads
> case tails
> }
>
> enum CoinState {
> case inAir
> case landed(showing: CoinSide)
> }
>
> print(CoinState.inAir)  // → "inAir"
>
> // …but…
>
> print(CoinState.landed(showing: .heads))  // → "landed(CoinSide.heads)"
>
> print([CoinSide.heads: 1])  // → "[CoinSide.heads: 1]"
>
> This is the case I was thinking of where the module name comes into play.
> Drop those enums into a framework, and you’ll get
> "landed(MyFramework.CoinSide.heads)". Ugh!
>
>
> This seems to be more of namespace “import” issue than a problem with enums
> specifically. Declaring enums within another entity is a useful. I take
> advantage of qualified naming to make short, possibly non-unique enum names.
>
>
> So what if you want those second two to print out as "landed(heads)" and
> "[heads: 1]”? This does not work:
>
> enum CoinSide: CustomStringConvertible {
> case heads
> case tails
>
> var description: String {
> return String(self) // infinite recursion
> }
> }
>
> There’s no automatically implemented description (or debugDescription)
> property we can delegate to. The conversion of .heads →  "heads" is
> apparently runtime magic that we lose access to as soon as we implement
> CustomStringConvertible or CustomDebugStringConvertible, and therefore AFAIK
> there's no way to do this other than switching on all the cases:
>
> enum CoinSide: CustomStringConvertible {
> case heads
> case tails
>
> var description: String {
> switch(self) {
> case heads: return "heads"
> case tails: return "tails"
> }
> }
> }
>
> Is is true that there’s no better way? Is there some
> CustomVerboseDebugStringConvertible protocol we can override to change only
> the "MyFramework.CoinSide.heads" form?
>
> If indeed there is no better way, it seems like a really good case for
> having the synthesized .caseName property. Even if there is a
> CustomVerboseDebugStringConvertible to override in the particular case
> above, being able to customize an enum’s description but still use the enum
> case name in that description seems like a compelling use case as well.
>
> Cheers, P
>
> On Jun 1, 2016, at 10:47 AM, Leonardo Pessoa  wrote:
>
> Paul, in all my tests for this thread printing the enum value only
> produced the enum value's name ("Mars" in your example). The proposal
> of having a .caseName (or should it better be .caseValue to cover
> enums with associated values? any other suggestions?) will prevent
> that changes to this behaviour crash apps in the future as this should
> always produce the same result even if the string representation
> changes.
>
> L
>
> On 1 June 2016 at 12:15, Paul Cantrell via swift-evolution
>  wrote:
>
> 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:
> https://github.com/bustoutsolutions/siesta/blob/master/Source/ResourceObserver.swift#L106-L115
>
> A clean, documented, supported way of exposing the enum case name that the
> runtime clearly already has available seems sensible — and should be
> independent of the raw type.
>
> Cheers, P
>
> On Jun 1, 2016, at 5:10 AM, Charlie Monroe via swift-evolution
>  wrote:
>
> This is, however, kind of a hack IMHO that relies on the compiler behavior
> that isn't well documented.
>
> For example, this:
>
> enum Planet {
>  case Earth
>  case Mars
> }
>
> "\(Planet.Mars)" // This is "Mars"
>
>
> Works as well. You don't need to have the represented value to be String.
>
> Note that this:
>
> - works both when you have a plain enum, or enum Planet: Int, or whatever
> raw value kind
> - does not work (!) when declared as @objc - then the result is "Planet".
>
> On Jun 1, 2016, at 9:52 AM, Patrick Smith via swift-evolution
>  wrote:
>
> I had no idea you could do this!!
>
> On 1 Jun 2016, at 12:32 PM, Brent 

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

[Leonardo Pessoa via swift-evolution]

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
constructors like the ones in Java enums;
- I never knew one could do that in Java but I think tuples can hold
function types;
- I also never heard one can do that in Java but I begin to think what
you really want are structs here;
- Both approaches here provide that, but accessors would allow for
dynamic content to be generated, not static.

Also Swift already allow for functions to be declared in enums and I
think this would be a better place than accessor properties to place
code that will generate dynamic results.

L

On 1 June 2016 at 11:59, Matthew Johnson via swift-evolution
 wrote:
>
>
> 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 sealed set of subclasses of the enum base type with 
>> (hopefully) immutable, singleton instances. So you can do fun things like:
>> - Define the base class constructor to be called to instantiate the 
>> subclasses, and declare the cases with the constructor arguments
>> - Declare a method on the base type and refine it on 1-2 particular cases
>> - Declare the enum implements an interface, and implement that interface 
>> separately for each case.
>> - Define data accessors specific to the type (such as the planets example 
>> above)
>>
>> I like the SuitInfo approach below - with extensions, I think I can get 
>> close to what I have done in the past with Java. Maybe one day there is 
>> syntax to do this in the language directly
>
> This is pretty similar to what we were discussing last week in this thread: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/018799.html
>
> I'm planning to write up a proposal when I have time (hopefully in the next 
> week or so).
>
>>
>> -DW
>>
>>> On May 31, 2016, at 11:44 AM, Vladimir.S via swift-evolution 
>>>  wrote:
>>>
>>> I'm not sure about my opinion on this proposal, but I believe you should 
>>> add this as alternatives of how we can have the similar features today 
>>> without injecting stored properties into enums  :
>>>
>>> enum Suit {
>>>   case spades
>>>   case hearts
>>>   case diamonds
>>>   case clubs
>>>
>>>   struct SuitInfo {
>>>   let simpleDescription: String
>>>   let color: UIColor
>>>   let symbol: String
>>>   let bezierPath: UIBezierPath
>>>   }
>>>
>>>   var info : SuitInfo {
>>>   switch self {
>>>   case .spades:
>>>   let path = UIBezierPath()
>>>   // omitted lines ...
>>>
>>>   return SuitInfo(
>>>   simpleDescription: "spades",
>>>   color: .blackColor(),
>>>   symbol: "♠",
>>>   bezierPath: path)
>>>
>>>   case .hearts:
>>>   let path = UIBezierPath()
>>>   // omitted lines ...
>>>
>>>   return SuitInfo(
>>>   simpleDescription: "hearts",
>>>   color: .redColor(),
>>>   symbol: "♥",
>>>   bezierPath: path)
>>>
>>>   case .diamonds:
>>>   let path = UIBezierPath()
>>>   // omitted lines ...
>>>
>>>   return SuitInfo(
>>>   simpleDescription: "diamonds",
>>>   color: .redColor(),
>>>   symbol: "♦",
>>>   bezierPath: path)
>>>
>>>   case .clubs:
>>>   let path = UIBezierPath()
>>>   // omitted lines ...
>>>
>>>   return SuitInfo(
>>>   simpleDescription: "clubs",
>>>   color: .blackColor(),
>>>   symbol: "♣",
>>>   bezierPath: path)
>>>
>>>   }
>>>   }
>>> }
>>>
>>> and this:
>>>
>>> enum Suit  {
>>>   case spades
>>>   case hearts
>>>   case diamonds
>>>   case clubs
>>>
>>>   struct SuitInfo  {
>>>   let simpleDescription: String
>>>   let color: UIColor
>>>   let symbol: String
>>>   let bezierPath: UIBezierPath
>>>   }
>>>
>>>   static let spadesInfo : SuitInfo = {
>>>   let path = UIBezierPath()
>>>   // omitted lines ...
>>>
>>>   return SuitInfo(
>>>   simpleDescription: "spades",
>>>   color: .blackColor(),
>>>   symbol: "♠",
>>>   bezierPath: path)
>>>   }()
>>>
>>>   static let heartsInfo : SuitInfo = {
>>>   let path = UIBezierPath()
>>>   // omitted lines ...
>>>
>>>   return SuitInfo(
>>>   simpleDescription: "hearts",
>>>   color: .redColor(),
>>>   symbol: "♥",
>>>   bezierPath: path)
>>>   }()
>>>
>>>   static let diamondsInfo : SuitInfo = {
>>>   

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

[Leonardo Pessoa via swift-evolution]

Unions have been discussed earlier in this group and I personally
think this is an issue better solved using function overloading.
Despite this, I see how union types could be implemented (hint:
Optionals) but to use it in code would require you to, at least, test
for the type of the value at hand for the blocks of different code
between types. It feels like trying to bend a static typed language to
work a bit like a dynamic typed and while both have their pros and
cons I don't really think there is any benefit for the programmer and
the readability of the code in bending the type checker like this.

L

On 1 June 2016 at 08:06, Haravikk via swift-evolution
 wrote:
> I agree the second is much nicer, and a lot clearer on what each of the
> options does; fitImage: true is pretty clear, but fitImage: false is not,
> but the ad-hoc enum is clear on both counts. That said, the questions of
> interoperability are a big issue for ad-hoc enums, as either they’re too
> strict which becomes inconvenient (a .Fit | .Fill working with one method
> but not another) or too relaxed to be safe. Of course, in the latter case
> you’re replacing a Bool, which couldn’t be more relaxed in terms of where it
> accepts values from.
>
> Still, I think in this case it would be better to fully-define an enum, as
> it gives you total control over compatibility and reusability of the type,
> which you can’t really with the ad-hoc form without making it overly
> complex.
>
> The main type of ad-hoc enum I want to see is a union-type like so:
>
> func someMethod(value:(Int | String)) { … }
>
> This would basically be an ad-hoc enum where each case identifies one of the
> possible types, and the value bound as that type. This works however because
> there’s no ambiguity in the meaning; an (Int | String) is the same wherever
> you use it, whereas a general-purpose ad-hoc enum is less clear, as an other
> method might also take .Fit and .Fill values, but these may have a slightly
> different meaning.
>
> So yeah, I like the idea in principle, but I think in practice it has too
> many headaches to overcome for it to be as simple as it first appears =(
>
> On 31 May 2016, at 17:16, Erica Sadun via swift-evolution
>  wrote:
>
> Here's a function signature from some code from today:
>
> func scaleAndCropImage(
> image: UIImage,
> toSize size: CGSize,
> fitImage: Bool = true
> ) -> UIImage {
>
>
> And here's what I want the function signature to actually look like:
>
> func scaleAndCropImage(
> image: UIImage,
> toSize size: CGSize,
> operation: (.Fit | .Fill) = .Fit
> ) -> UIImage {
>
>
> where I don't have to establish a separate enumeration to include ad-hoc
> enumeration-like semantics for the call. A while back, Yong hee Lee
> introduced anonymous enumerations (and the possibility of anonymous option
> flags) but the discussion rather died.
>
> I'm bringing it up again to see whether there is any general interest in
> pursuing this further as I think the second example is more readable,
> appropriate, and Swifty than the first, provides better semantics, and is
> more self documenting.
>
> Thanks for your feedback,
>
> -- Erica
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

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

Then I can no longer rely on the compiler to fill string raw values
for me to use.

L

On 1 June 2016 at 07:59, Vladimir.S <sva...@gmail.com> wrote:
> Try this:
>
> enum Size: String { case Fit, Fill }
> print(Size.Fit.rawValue)
>
> On 01.06.2016 13:42, Leonardo Pessoa via swift-evolution wrote:
>>
>> Just a fix. I've just tried the following code and the compiler complained
>> there is no .rawValue on the type.
>>
>> |   enum Size { case Fit, Fill }
>> |   print(Size.Fit.rawValue)
>>
>> Then, as I said before, you can only get the value name as a string from
>> interpolation and need to do everything by hand the other way around.
>>
>> L
>>
>> ---
>> From: Charlie Monroe via swift-evolution
>> <mailto:swift-evolution@swift.org>
>> Sent: ‎01/‎06/‎2016 07:19 AM
>> To: Brent Royal-Gordon <mailto:br...@architechies.com>
>> Cc: Swift-evolution <mailto:swift-evolution@swift.org>
>>
>> Subject: Re: [swift-evolution] Working with enums by name
>>
>> Sorry, must've missed that.
>>
>>> On Jun 1, 2016, at 12:17 PM, Brent Royal-Gordon <br...@architechies.com>
>>
>> wrote:
>>>
>>>
>>>> This is, however, kind of a hack IMHO that relies on the compiler
>>
>> behavior that isn't well documented.
>>>
>>>
>>> It's documented in "The Swift Programming Language", in the same
>>
>> paragraphs where the `enum Planet` example we've been working with comes
>> from.
>>>
>>>
>>> “When you’re working with enumerations that store integer or string raw
>>
>> values, you don’t have to explicitly assign a raw value for each case.
>> When
>> you don’t, Swift will automatically assign the values for you.
>>>
>>> 
>>> “When strings are used for raw values, the implicit value for each case
>>
>> is the text of that case’s name.”
>>>
>>>
>>> --
>>> Brent Royal-Gordon
>>> Architechies
>>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

Just a fix. I've just tried the following code and the compiler complained 
there is no .rawValue on the type.

|   enum Size { case Fit, Fill }
|   print(Size.Fit.rawValue)

Then, as I said before, you can only get the value name as a string from 
interpolation and need to do everything by hand the other way around.

L

-Original Message-
From: "Charlie Monroe via swift-evolution" 
Sent: ‎01/‎06/‎2016 07:19 AM
To: "Brent Royal-Gordon" 
Cc: "Swift-evolution" 
Subject: Re: [swift-evolution] Working with enums by name

Sorry, must've missed that.

> On Jun 1, 2016, at 12:17 PM, Brent Royal-Gordon  
> wrote:
> 
>> This is, however, kind of a hack IMHO that relies on the compiler behavior 
>> that isn't well documented.
> 
> It's documented in "The Swift Programming Language", in the same paragraphs 
> where the `enum Planet` example we've been working with comes from.
> 
> “When you’re working with enumerations that store integer or string raw 
> values, you don’t have to explicitly assign a raw value for each case. When 
> you don’t, Swift will automatically assign the values for you.
> 
> “When strings are used for raw values, the implicit value for each case is 
> the text of that case’s name.”
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

In this case of not using raw values in an enum, can you use init(rawValue:) as 
in my proposal?

L

-Original Message-
From: "Charlie Monroe via swift-evolution" 
Sent: ‎01/‎06/‎2016 07:19 AM
To: "Brent Royal-Gordon" 
Cc: "Swift-evolution" 
Subject: Re: [swift-evolution] Working with enums by name

Sorry, must've missed that.

> On Jun 1, 2016, at 12:17 PM, Brent Royal-Gordon  
> wrote:
> 
>> This is, however, kind of a hack IMHO that relies on the compiler behavior 
>> that isn't well documented.
> 
> It's documented in "The Swift Programming Language", in the same paragraphs 
> where the `enum Planet` example we've been working with comes from.
> 
> “When you’re working with enumerations that store integer or string raw 
> values, you don’t have to explicitly assign a raw value for each case. When 
> you don’t, Swift will automatically assign the values for you.
> 
> “When strings are used for raw values, the implicit value for each case is 
> the text of that case’s name.”
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

Yes, you can do all this but you still have to do everything yourself by hand. 
Dictionary, plist, it even init as my initial example but you are the one 
responsible to control when e.g. you add a new value or rename another.

My proposal causes no big changes and no big overload on the compiler; it just 
adds an init method to find the equivalent enum value for a string. And yes 
this feature becomes a lot more interesting should the idea of using tuple 
typed enums goes forward but they are completely independent.

L

-Original Message-
From: "Patrick Smith" 
Sent: ‎01/‎06/‎2016 04:52 AM
To: "Brent Royal-Gordon" 
Cc: "Leonardo Pessoa" ; "Swift-evolution" 

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

I had no idea you could do this!!

> On 1 Jun 2016, at 12:32 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> Who said anything about repeating the name?
> 
> Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). 
> Type :help for assistance.
>  1> enum Planet: String { case mercury, venus, earth, mars, jupiter, saturn, 
> uranus, neptune }
>  2> Planet.mercury.rawValue
> $R0: String = "mercury"

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

If I got the idea right, you would need to implement yourself the protocol 
methods to answer for both init(rawValue: Int) and init(rawValue: String) - 
which is how you have to do today only with the string part - while my proposed 
approach you'd have to implement nothing yourself.

L

> On 31 May 2016, at 7:19 pm, Austin Zheng via swift-evolution 
>  wrote:
> 
> If we had generic protocols, you could implement RawRepresentable twice, once 
> using Ints and one using Strings. But that's probably never going to happen.
> 
> /digression
> 
> Austin
> 
>> On Tue, May 31, 2016 at 3:11 PM, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> > On May 31, 2016, at 4:07 PM, Brent Royal-Gordon via swift-evolution 
>> >  wrote:
>> >
>> >> • also wants OptionSetType-like behavior (and thus an Int raw type).
>> >
>> > Then it's not an `enum`, it's a `struct`.
>> 
>> You can get it for free as an array of enums and test with contains vs member
>> 
>> -- E, who has probably digressed more than she really should
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

Don't you think it's a bit of a waste to be repeating the name of the value as 
a string just to use init(rawValue:) with them? What if I need to store another 
string associated with the value of the enum e.g. I want to create an enum to 
represent options in a menu and the associated value is to be the name of the 
image file to be used for that option? I don't know how common that is, but I 
don't see how good it is for you to keep repeating yourself in your code when 
the value you want and need is right by your side (DRY principle) and can be 
used easily in one way (to string) but not the other (back to enum).

L

On 31 May 2016, at 6:48 pm, Brent Royal-Gordon  wrote:

>> |   enum Planet : Int {
>> |  case Mercury = 1, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune
>> |
>> |  init?(caseName name : String) {
> 
> The compiler actually does this already through RawRepresentable if you put 
> `String` as your raw type. So what's the use case for this? Code which needs 
> both a non-String rawValue *and* needs to look up cases by name? How common 
> do you think that is?
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

I'd actually like to see a change in guard so that I don't need those
braces. I'd like something more readable like

|   guard cond1 or return nil
|   guard cond2 or throw MyError.IllegalValue
|   guard cond3 or do { ... }

It may add more cases for the compiler to handle but in all cases I
used guard so far the block was never really needed. But I think this
is out of the scope of this thread.

L

On 31 May 2016 at 15:59, Adrian Zubarev via swift-evolution
 wrote:
> +1. This is example *is not* a single expression code block. There are 3
> expressions (the condition, the return value in the else block, and the
> primary return value).
>
> The `else` block is a returning single expression block. I can’t show the
> `guard` example without any returning scope.
>
> You said it yourself "everywhere in the language“. It’s not “everywhere“ if
> we would left out `guards` else-returning block.
>
> If we’d allow this we could also write:
>
> func test(boolean: Bool) {
> guard boolean else {}
> print("true")
> }
>
> This is useless and less readable.
>
> But we already can do this with closures:
>
> let nop = {} // useless
>
> switch value {
>...
>default: {}() // do nothing
> }
>
> --
> Adrian Zubarev
> Sent with Airmail
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Working with enums by name

[Leonardo Pessoa via swift-evolution]

Since we're talking a lot enums these days, I'd like to bring into
discussion a proposal that has been briefly mentioned in another
thread to enable working with enums using their names.

This is currently possible in the language but it's a bit burdensome.
You can just interpolate the value of the enum into a string to get
its name/representation as a string but you have to write case by case
the init methods for each enum to convert the string back to its
value. For example:

|   enum Planet : Int {
|  case Mercury = 1, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune
|
|  init?(caseName name : String) {
|  switch name {
|  case "Mercury":
|  self = .Mercury
|  case "Venus":
|  self = .Venus
|  case "Earth":
|  self = .Earth
|  case "Mars":
|  self = .Mars
|  case "Jupiter":
|  self = .Jupiter
|  case "Saturn":
|  self = .Saturn
|  case "Uranus":
|  self = .Uranus
|  case "Neptune":
|  self = .Neptune
|  default:
|  return nil
|  }
|  }
|   }
|
|   let planet = Planet(caseName: "Earth")!
|   print("\(planet) = \(planet.rawValue)") // Earth = 3

My proposal here is to let the compiler create these initialisers
automatically, just like with rawValue.

The reasoning here is simple: Enums in their basics are values, like
Int values or Double values, but limited to a closed set and
referenced in code by a name. Although they *may* have raw value
equivalents not all do (they don't need to). Using the name of the
enum value instead of any value associated with it also benefits
persistence since these associated values can change overtime while
the name is less likely to change.

As an example of the importance of this proposal, I mention the
company I work for who chooses to store (DB) the names of enum values
where they are used in persisted data arguing it's easier to debug and
support, and several web services we work with send enumerated values
as the strings of their names which we have to convert back to the
enum value when we receive. This proposal would simplify writing such
parts of the apps.

In case you're thinking, enums with associated values can also have
their instances created this way because there seems to be a default
representation for them in string interpolation. It's possible to be
done manually but would require a lot more of code and effort to be
converted back:

|   enum Platform {
|  case OSX(version: String)
|  case iOS(version : Int)
|   }
|
|   let plat = Platform.iOS(version: 9)
|   print("\(plat)") // iOS(9)
|
|   let plat2 = Platform.OSX(version: "10.10.4")
|   print("\(plat2)")  // OSX("10.10.4")

Furthermore, I'm aware the output of the string interpolation may be
altered by adopting certain protocols so it should also be interesting
for this proposal to add a property like .caseName to all enums to
ensure the correct string representation that would be converted back
to the enum value.

I'd like to hear your opinions before writing a proposal.
Thanks.

L
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

This is interesting. I don't think there is anything preventing these
to be internally translated by the compiler as a true enums with
random names (or
any-other-way-we-shall-never-be-able-to-reference-again) thus adding
the needed ObjC interop.

L

On 31 May 2016 at 13:24, Charlie Monroe via swift-evolution
 wrote:
> Most ideas discussed here lately cannot be used from ObjC.
>
>> On May 31, 2016, at 6:20 PM, Kevin Nattinger via swift-evolution 
>>  wrote:
>>
>> Definitely an interesting idea, and I like it, but how would this be used 
>> from Objective C?
>>> On May 31, 2016, at 9:16 AM, Erica Sadun via swift-evolution 
>>>  wrote:
>>>
>>> Here's a function signature from some code from today:
>>>
>>> func scaleAndCropImage(
>>>image: UIImage,
>>>toSize size: CGSize,
>>>fitImage: Bool = true
>>>) -> UIImage {
>>>
>>>
>>> And here's what I want the function signature to actually look like:
>>>
>>> func scaleAndCropImage(
>>>image: UIImage,
>>>toSize size: CGSize,
>>>operation: (.Fit | .Fill) = .Fit
>>>) -> UIImage {
>>>
>>>
>>> where I don't have to establish a separate enumeration to include ad-hoc 
>>> enumeration-like semantics for the call. A while back, Yong hee Lee 
>>> introduced anonymous enumerations (and the possibility of anonymous option 
>>> flags) but the discussion rather died.
>>>
>>> I'm bringing it up again to see whether there is any general interest in 
>>> pursuing this further as I think the second example is more readable, 
>>> appropriate, and Swifty than the first, provides better semantics, and is 
>>> more self documenting.
>>>
>>> Thanks for your feedback,
>>>
>>> -- Erica
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

+1

L

On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution
 wrote:
>
>> On May 28, 2016, at 3:09 AM, David Hart via swift-evolution 
>>  wrote:
>>
>> It isn’t a special case because all other single-statement closures in the 
>> language work that way. It’s actually inconsistent now.
>
> Computed properties aren’t closures so it’s not inconsistent in that sense.  
> But it is inconsistent in that closures are the *only* value-returning code 
> blocks that are able to use this sugar.  It would be nice to see this sugar 
> consistently allowed everywhere in the language.
>
>>
>>> On 28 May 2016, at 09:03, Brian Christensen via swift-evolution 
>>>  wrote:
>>>
>>> On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution 
>>>  wrote:
>>>
 The idea is simple:

 • Can we make return keyword optional in cases like this?
 • Shouldn’t this behave like @autoclosure or @noescape?
 type A {
   var characters: [Character] = …
   var string: String { String(self.characters) }
   var count: Int { 42 }
 }

 Is this worth a proposal or Swifty enough, what do you think?

 Sure I could write return, but why do we allow this behavior for @noescape 
 functions like map!?
>>>
>>> While I am not necessarily against this idea, I do wonder if it’s worth 
>>> making what’s going on here less obvious simply for the sake of being able 
>>> to omit a six character keyword. As I understand it, one of the reasons 
>>> ++/-- were removed was due to the increased "burden to learn Swift as a 
>>> first programming language.” This is the sort of thing that becomes another 
>>> one of those special cases that has to be explained to someone new to Swift.
>>>
>>> /brian
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

In your alternatives considered, you mention "not all TODO or FIXME
comments should surface" but I think the opposite: if I want these
types of comments to be seen as warnings by the compiler I cannot
choose which will surface and which not. It would be the same as
saying "hey, but I don't want all #warnings to surface or I may have a
lot in my list" too. Most programming languages work with these "tags"
(should we call them that?) in comments and offer to show you where
these are when you want to see them. Perhaps that's what you're saying
not all of them should surface but if you meant other things that
should be tagged like this and not surface, you should consider using
a different tag that will not surface.

Furthermore, I believe these tags are merely informational and should
not be the reason for using #warnings. Perhaps a comment analysis
pointing out where in your project you have tagged comments should
suffice. That would also solve the issue of misspelling the tag as
FIXME and FIXEM would both show in. And if you don't want to care
about FIXME tags at a certain time you could tell the IDE to skip them
and FIXEM will surface making you realise you misspelled it.

L

On 28 May 2016 at 21:55, Robert Widmann via swift-evolution
 wrote:
> +1.  This is definitely a useful feature to have and helps advance a clear
> and common pattern among programmers in general.
>
> On May 28, 2016, at 4:58 PM, Harlan Haskins via swift-evolution
>  wrote:
>
> Hey everyone,
>
> I’m working on a draft for #warning in Swift. I’ve implemented the draft as
> it stands, and it’s pretty nice to work with.
>
> I’ve pasted it below, and I’d love some feedback! Thanks!
>
> — Harlan Haskins
>
>
>
> #warning
>
> Proposal: SE-
> Author: Harlan Haskins
> Status: Awaiting review
> Review manager: TBD
>
> Introduction
>
> It's really common for developers to add TODO/FIXME comments in their source
> code, but there currently isn't a supported facility to make these visible.
> People have implemented special workarounds to coax Xcode into emitting
> TODOs and FIXMEs as warnings, but there isn't an accessible way to provide
> arbitrary warnings, and does not work in a non-Xcode environment.
>
> Motivation
>
> A #warning is for something you intend to fix before submitting your code or
> for writing future tasks that you or your teammates intend to complete
> later. Because this is such a common programming pattern, Swift should have
> a similar facility.
>
> Proposed solution
>
> Add #warning(_:) as a new compiler directive that emits a warning diagnostic
> with the contents, pointing to the start of the message.
>
> func configPath() -> String {
>   #warning("TODO: load this more safely") // expected-warning {{TODO: load
> this more safely}}
>   return Bundle.main().path(forResource: "Config", ofType: "plist")!
> }
>
> Detailed design
>
> This will add two new productions to the Swift grammar:
>
> compiler-control-statement → warning-directive
> warning-directive → #warning( static-string-literal )
>
> Upon parsing this statement, the Swift compiler will immediately emit a
> warning and discard the statement.
>
> If a #warning exists inside a branch of a #if statement that is not taken,
> then no warning is emitted.
>
> #if false
> #warning(“This won’t exist”)
> #endif
>
> Impact on existing code
>
> This change is purely additive; no migration will be required.
>
> Alternatives considered
>
> We could do some kind of comment-parsing based approach to surface TODOs and
> FIXMEs, but #warning serves as a general-purpose facility for reporting at
> compile time. Plus, not all TODO or FIXME comments should surface as
> warnings in the source.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> ~Robert Widmann
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

Just complementing as I was on the run when I saw and responded the
previous message.

In my proposal, we would be allowing tuples to be used as if they were
value types in enums.

|   enum Planet : (mass: Double, radius: Double) {
|   case Mercury = (mass: 3.303e+23, radius: 2.4397e6)
|   case Venus = (mass: 4.869e+24, radius: 6.0518e6)
|   case Earth = (mass: 5.976e+24, radius: 6.37814e6)
|   case Mars = (mass: 6.421e+23, radius: 3.3972e6)
|   case Jupiter = (mass: 1.9e+27, radius: 7.1492e7)
|   case Saturn = (mass: 5.688e+26, radius: 6.0268e7)
|   case Uranus = (mass: 8.686e+25, radius: 2.5559e7)
|   case Neptune = (mass: 1.024e+26, radius: 2.4746e7)
|   }

Since tuples cannot be tested for uniqueness (I'd even go further to
say this would be undesireable here), you would also not have the
init(rawValue:) method testing for tuples and thus you would not have
the rawValue property of single typed enums returning the tuple
either, just like non-typed enums (calling .rawValue on a non-typed
enum will return the enum value itself, thus calling
Planet.Mercury.rawValue would return .Mercury itself here too). This
imposes no changes on existing code and allows for the values to be
refered to directly without using .rawValue in the middle (e.g.
print(Planet.Mercury.radius) instead of
print(Planet.Mercury.rawValue.radius)). You could even think of
internally representing single typed enums using a single value tuple
like the following:

|   enum Order : Int {
|   case First = 1
|   case Second
|   case Third
|   case Fourth
|   }

could be still declared like this but be internally represented as if it were:

|   enum Order : (rawValue: Int) {
|   case First = (rawValue: 1)
|   case Second = (rawValue: 2)
|   case Third = (rawValue: 3)
|   case Fourth = (rawValue: 4)
|   }

But that's just a simplification for internal representation and may
not even be used (I think this will be left for the Apple team to
decide how it should be implemented, either way current raw values
won't be broken).

IMO, this proposal only expands the possible set of values a typed
enum can hold using a syntax that is as close to the current one as I
think possible. Enums are, as defined in the Swift documentation, "a
common type for a group of related **values**" afterall and it makes
no sense to me to associate computed properties (which could return
different values each time they're called) to store constant value
properties and it's also much more verbose. Tuples can do this job
much better, cleaner and efficiently. You may also remember enums with
associated values: their values are defined when the enum is
initialised and never change either; you may create a new instance
with new values derived from another instance but you can never change
the values of an instance. Thus allowing an enum value to hold a
computed property seem like we're changing enums into something else.

Just one more idea to bring to this proposal, I thought there could be
a way to still have the init(rawValue:) method using tuples by simply
declaring one of the values of the tuple to be rawValue itself. The
compiler would enforce the uniqueness of values in this field and the
initialiser could find the enum value by its raw value, like this:

|   enum Planet : (mass: Double, radius: Double, rawValue: Int) {
|  case Mercury = (mass: 3.303e+23, radius: 2.4397e6, rawValue: 1)
|  case Venus = (mass: 4.869e+24, radius: 6.0518e6, rawValue: 2)
|  case Earth = (mass: 5.976e+24, radius: 6.37814e6, rawValue: 3)
|  case Mars = (mass: 6.421e+23, radius: 3.3972e6, rawValue: 4)
|  case Jupiter = (mass: 1.9e+27, radius: 7.1492e7, rawValue: 5)
|  case Saturn = (mass: 5.688e+26, radius: 6.0268e7, rawValue: 6)
|  case Uranus = (mass: 8.686e+25, radius: 2.5559e7, rawValue: 7)
|  case Neptune = (mass: 1.024e+26, radius: 2.4746e7, rawValue: 8)
|   }

and thus allow the following code:

|   let planet = Planet(rawValue: 4)!
|   print(planet.mass)

You may argue this is hard to read the more fields the tuple holds,
but there is nothing preventing you from formating your code in
another way, for example:

|   enum Planet : (mass: Double, radius: Double, rawValue: Int) {
|  case Mercury = (
|  mass: 3.303e+23,
|  radius: 2.4397e6,
|  rawValue: 1
|  )
|  case Venus = (
|  mass: 4.869e+24,
|  radius: 6.0518e6,
|  rawValue: 2
|  )
|  // 

That was my proposal for the problem you presented.

On 31 May 2016 at 11:23, Leonardo Pessoa  wrote:
> As I said before, I'm not in favour of this approach. And you completely
> missed my proposal in the alternatives.
>
> 
> From: Jānis Kiršteins
> Sent: ‎31/‎05/‎2016 11:17 AM
> To: Leonardo Pessoa
> Cc: Brent Royal-Gordon; swift-evolution
> Subject: Re: [swift-evolution] [Proposal] Enums with static stored
> propertiesfor each case
>

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

[Leonardo Pessoa via swift-evolution]

Fréderic, the idea and reasoning are good and do make sense but I'm
not 100% go on this. When I started using this syntax I felt like I
was back in PHP but once I got used it's ok. I don't see anything
wrong that justifies the change in syntax. Looking at your examples I
even think it's easier to spot "$n" in my code than ".n".


On 30 May 2016 at 13:44, Frédéric Blondiau  wrote:
> Hello,
>
> I was thinking about this, and would like to get some feedback before making 
> my first proposal.
>
> Best regards,
>
>
> Fred.
> ---
>
> Shorthand Argument Renaming
>
>
> Introduction
>
> Swift automatically provides shorthand argument names to inline closures 
> which cleverly allows us to write
>
> reversed = names.sort( { $0 > $1 } )
>
> I would suggest to use another syntax, using these new “names”
>
> reversed = names.sort( { .0 > .1 } )
>
>
> Motivation
>
> The $n notation is generally used with positional parameters using one-based 
> numbering, $1 referring to argument 1; $2, to argument 2... with a special 
> meaning for $0 (could be the name of the function, or the full list of 
> parameters).
>
> This $n notation is often handy, but feels strange in Swift... like imported 
> from UNIX scripting (but here zero-based, anyway).
>
>
> Proposed solution
>
> The .n notation is more Swift-like — as used to access Tuple members, for 
> example.
>
>
> Detailed design
>
> Today, .0 or .1 (as any .n's) are refused by the compiler, as being not valid 
> floating point literals.
>
> I’m not a compiler expert, but eventually fetching this error inside a 
> closure body could easily be translated into accepting this new syntax.
>
> There can’t be conflict with other shorthands (like accessing static members 
> using dot notation) as members can’t consist of only digits characters.
>
>
> Impact on existing code
>
> $n need to be rewritten .n
>
>
> Alternatives considered
>
> Create a default argument named “arguments” (like “error” in catch, 
> “newValue” in setters or “oldValue” in a a didSet observer) accessed like a 
> Tuple
>
> reversed = names.sort( { arguments.0 > arguments.1 } )
>
> but this is (of course) much less convenient.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

Tools like SonarQube can raise a "warning" for comments started with "TODO:" or 
"FIXME:". Wouldn't it be more interesting if those could be presented as 
warnings instead of using #warning? And this could be an optional setting as 
commented would not influence compilation.



-Original Message-
From: "Will Stanton via swift-evolution" 
Sent: ‎29/‎05/‎2016 07:09 PM
To: "Harlan Haskins" 
Cc: "swift-evolution" 
Subject: Re: [swift-evolution] [Pitch] #warning

+1 to #warning or optionally(?) emitting something like TODO: more visibly!

In past ObjC projects, I have used #warning to confirm the right macros were 
enabled.

I often (1) work around differences between the iOS simulator and device with 
TARGET_IPHONE_SIMULATOR (+similar) and (2) change API endpoints among sandbox, 
production, etc… (which may not relate to whether the open project is 
debug/release)
For instance, I have code like:
#if TARGET_IPHONE_SIMULATOR || API_DEBUG
[Declarations]
#warning DEBUG API: Do not release
#else
[Different declarations]
#endif

I check that release builds do not emit a “warning Do not release” before 
submitting/deploying.


I think it would be great if (1) lines/branches of Swift source with #warning 
or something like INDICATE: are highlighted and (2) FIXMEs, TODOs, warnings, 
etc… are emitted and put into the Issues Navigator of Xcode.

In the past, both of the above (line highlighting and the ease of checking the 
Issues Navigator for “warning: Do not release” in Xcode) were conducive to my 
sanity:
Issue highlighting from the last build seems more reliable than syntax 
highlighting. Xcode syntax highlighting colors (1) sometimes goes down (I’ve 
encountered SourceKit crashes pretty often) or (2) is wrong (perhaps macros 
weren’t detected correctly).
Also, while (3) using schemes and (4) seeing the -Doptions in the build command 
are useful, they are less visible by themselves.

Regards,
Will Stanton

> On May 29, 2016, at 4:20 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> As to #warning, Swift’s use of warnings are significant different than the 
> use in C. In C compilers, many of the warnings produced *should* be errors, 
> but can’t be because that effects language conformance and could break a 
> large body of code. Swift doesn’t have this problem, so it treats warnings as 
> “things that should be addressed before you commit your patch, but shouldn’t 
> block a build if (e.g.) you’re in the middle of a big refactoring”.  For 
> example, an unused variables is a warning in Swift.
> 
> This difference in policy is what makes me question where #warning makes 
> sense for Swift.  OTOH, errors in Swift are used in exactly the same way as 
> in C compilers, which is why bringing #error forward makes sense to me.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

I think that's the case with enums. You're changing their current behaviour of 
only having stored values to one in which it's computed (even if only once and 
then stored). Enums are IMO something that have a static value you know 
beforehand and can count on. That's why I'm not fond of the accessor proposal. 
Otherwise I think we're transforming enums into a closed set of struct 
instances and one could do that already by using a private init.


> On 29 May 2016, at 3:38 am, Jānis Kiršteins via swift-evolution 
>  wrote:
> 
> I agree with the argument about use of "where", not replacing the raw
> value and having some kind of initialization block. But I cannot see
> why "accessors" concept is any better than stored properties to solve
> the particular problem. The "accessors" concept has much wider scope
> than enums and is a separate proposal.
> 
> On Sat, May 28, 2016 at 11:39 PM, Brent Royal-Gordon
>  wrote:
 - Abusing rawValue is just that: an abuse.
>>> 
>>> My original proposal does not replace rawValue and is compatible with it.
>> 
>> `rawValue` has a different purpose from how you're using it. It's supposed 
>> to allow you to convert your type to some other *equivalent* type, like an 
>> equivalent integer or string. Moreover, it's supposed to allow you to 
>> *reconstruct* the instance from the raw value—remember, `RawRepresentable` 
>> has an `init(rawValue:)` requirement.
>> 
>> It is *not* supposed to be an ancillary bag of information on the side. 
>> You're cramming a square peg into a round hole here.
>> 
>> (Also, if you use `rawValue` for an ancillary bag of information, that means 
>> you *can't* use it on the same type for its intended purpose. For instance, 
>> you would not be able to assign numbers to your Planet enum's cases to help 
>> you serialize them or bridge them to Objective-C. That's not good.)
>> 
 - Using `where` just doesn't match the use of `where` elsewhere in the 
 language; everywhere else, it's some kind of condition.
>>> 
>>> It is also used in generic type constraints. Plus it reads like human
>>> language: `case mercury where (mass: 3.303e+23, radius: 2.4397e6)`
>> 
>> But a generic constraint is also a type of condition: it specifies types 
>> which are permitted and divides them from types that are not.
>> 
>> This is *not* a condition. It's not anything like a condition. It's simply 
>> not consistent with anything else in the language.
>> 
 - Dictionaries are the most straightforward way to handle this with the 
 current language, but their lack of exhaustiveness checking is a problem.
>>> 
>>> Dictionaries can be used as workaround, but they cannot (lack of
>>> exhaustiveness) solve the problem.
>> 
>> I agree that they're a halfway solution.
>> 
>> If `ValuesEnumerable` were to be accepted (and to have a generic requirement 
>> for its `allValues` property), you could write a Dictionary-like type which 
>> ensured at initialization time that it was exhaustive. That's not as good as 
>> compile time, but it's not bad—sort of a three-quarters solution.
>> 
>>struct ExhaustiveDictionary> ValuesEnumerable>: Collection, DictionaryLiteralConvertible {
>>private var dictionary: [Key: Value]
>> 
>>init(dictionaryLiteral elements: (Key, Value)...) {
>>dictionary = [:]
>>for (k, v) in elements {
>>dictionary[k] = v
>>}
>> 
>>if dictionary.count != Key.allValues.count {
>>let missingKeys = Key.allValues.filter { 
>> dictionary[$0] == nil }
>>preconditionFailure("ExhaustiveDictionary is 
>> missing elements from \(Key.self): \(missingKeys)")
>>}
>>}
>> 
>>var startIndex: Dictionary.Index {
>>return dictionary.startIndex
>>}
>>var endIndex: Dictionary.Index {
>>return dictionary.endIndex
>>}
>>subscript(index: Dictionary.Index) -> (Key, Value) {
>>return dictionary[index]
>>}
>>func index(after i: Dictionary.Index) -> Dictionary.Index {
>>return dictionary.index(after: i)
>>}
>> 
>>subscript(key: Key) -> Value {
>>get { return dictionary[key]! }
>>set { dictionary[key] = newValue }
>>}
>>}
>> 
 What I would do is borrow the "accessors" concept from the property 
 behaviors proposal and extend it so that it supported both functions and 
 variables.
>>> 
>>> Wouldn't accessor just be a redundant keyword here? Currently enums do
>>> not support stored properties, so I guess there is no extra need to
>>> mark 

Re: [swift-evolution] Variadic generics discussion

[Leonardo Pessoa via swift-evolution]

I hate C++ generics. Just thought about sharing this.


> On 29 May 2016, at 9:00 am, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On May 29, 2016, at 1:22 AM, Austin Zheng  wrote:
>> 
>> Thank you for reading through the proposal! 
>> 
>>> On May 28, 2016, at 7:41 PM, Matthew Johnson  wrote:
>>> 
>>> These are some very good and clearly articulated examples.  Great work!  
>>> This section is important because variadics are somewhat complicated and it 
>>> is important to show people why we want them and what problems they can 
>>> solve.
>> 
>> Any more practical use cases you can come up with (preferably ones that are 
>> distinct from the few we have now) would be greatly appreciated.
>> 
>> My thinking is that it's best to keep the feature as described in this 
>> proposal as lightweight as possible, proposing only enough expressiveness so 
>> that most reasonable use cases can be expressed. There are two reasons for 
>> that:
>> 
>> - Design and implementation burden relative to benefit. This is not a 
>> top-priority feature in the manifesto, and will be competing with at least 
>> two or three other features for resources. It's also quite complicated, 
>> as-is. It will affect how Swift handles resilience. [*]
>> - This proposal should not become a variadic generics proposal with a 
>> half-thought-out compile time metaprogramming scheme hanging off it. What 
>> Swift gets in terms of macros, code generation, or compile-time expressions 
>> deserves a conversation of its own eventually.
> 
> Very much agree with the comments about compile time meta programming here.  
> I'm really looking forward to that but we can do far better than C++ here.  
> 
>> 
>> More concretely, D has a "static if" construct 
>> (https://dlang.org/variadic-function-templates.html). It looks really nice - 
>> you could write a n-arity function that generates a `print("Hello, 
>> Matthew")` only if its arity is 3. I'm sure there are many use cases for it. 
>> Is building something similar worth spending time for during the Swift 3.x 
>> timeframe? Probably not, especially if it could be implemented in the future 
>> and the existing variadic generic semantics seamlessly extended to work with 
>> it.
>> 
>>> 
 
 There is a lot of scope for design refinements, and even for alternative 
 designs. With enhanced existentials, there was already an informal 
 consensus that the feature would involve composing some protocols and 
 class requirements, and placing constraints on the associated types, and 
 most everything else was working out the various implications of doing so. 
 That's not true for this feature.
 
 In particular, I'm interested to see if there are similarly expressive 
 designs that use exclusively tuple-based patterns and no parameter packs. 
 I think Rust once considered a similar approach, although their proposal 
 ended up introducing a parameter-pack like construct for use with fn 
 application: https://github.com/rust-lang/rfcs/issues/376
>>> 
>>> As far as I can tell, the way you are approaching `apply` would not allow 
>>> the default arguments of the function passed as `function` to be used when 
>>> calling `apply`.  Arguments would have to be provided for all parameters 
>>> when the function is invoked through apply.
>> 
>> Yes. There are a lot of issues right now with the idea of using a value pack 
>> or a tuple to call a function, and most of them apply to the tuple splat 
>> discussion that took place a few months ago. Namely, the idea of a tuple or 
>> 'vector' of values does not map cleanly to Swift's function parameter 
>> conventions. You have inout params, params with default values, argument 
>> labels, and other stuff that tuples can't represent cleanly or at all.
>> 
>>> 
>>> I know that this difficulty is not directly related to variadic generics, 
>>> but it does demonstrate a limitation of this approach to forwarding.
>>> 
>>> I have already run into a use case where I would like to accept a function 
>>> and a pack of arguments, store the arguments, be able to compare them for 
>>> equality, and later invoke the function with them.  However, in order for 
>>> this approach to make sense in my use case it would be essential that the 
>>> user *not* need to explicitly provide arguments for parameters with 
>>> defaults.
>>> 
>>> I bring this up in hopes that we might try to explore designs that would 
>>> support this use case, and at least give it some consideration.  I’m trying 
>>> to think of ways to make this work but haven’t come up with anything 
>>> obvious yet.
>> 
>> I do want to explore designs in this space, and I think we will need to 
>> figure it out at some point.
>> 
>> If a good solution cannot present itself in the time frame, I'd be willing 
>> to punt for the purposes of this proposal.
> 
> I am ok with 

Re: [swift-evolution] [Proposal] Protected Access Level

[Leonardo Pessoa via swift-evolution]

> attempting to write a Swift compiler in Swift today would probably result in 
> hard to read/reason about source code. 

Hmm, I still have to find some time to start working in this...
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Leonardo Pessoa via swift-evolution]

You know the default access is was is used for this, right? And in this case I 
don't think they meant it for external subclasses to be able to access this 
change.

I think this is how Swift was meant to work allowing only classes in a certain 
module to access such "private shared" parts and using delegates for these 
extensions. I'm not saying I'm against protecteds but it's hard to get used to 
use another way of programming when most other languages we previously learned 
had a different philosophy.

Sure everyone has the right to discuss they like this new philosophy or not but 
we should also question ourselves if this is the right way to go because it 
will completely change the philosophy of the language. Should this pass, we may 
start facing the core library using the delegate philosophy (I don't believe 
Apple will change it) and third-party modern frameworks using old school 
subclassing with protected parts. That's two ways of doing the same thing and I 
don't think this will be much good to anyone.


-Original Message-
From: "Charlie Monroe via swift-evolution" 
Sent: ‎29/‎05/‎2016 08:29 AM
To: "Brent Royal-Gordon" 
Cc: "swift-evolution" 
Subject: Re: [swift-evolution] [Proposal] Protected Access Level


> My answer is this: There is nothing magical about being a subclass that ought 
> to grant access to those methods.

There is - it's a family member that you let use your summer house. Without the 
metaphor, here is an example for this being useful: 

URLConnection subclass may want to update the URL in case of a redirect, but 
you don't really want to expose the setter for the URL to public.

> For instance, if your subclass grows very complicated and you extract a 
> helper object, it's perfectly reasonable for that helper object to want to 
> access the "subclass-only" API.

That's what "friend" classes are for in C++, similar concept would be applied 
here.

> Contrarily, simple subclasses might not need that API, and exposing it to 
> them would be an unnecessary risk. And there are things which you don't 
> subclass at all which could benefit from being hidden away—think of the 
> Objective-C runtime, which has some parts which every app needs (like the 
> definition of `BOOL`) and othe

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Leonardo Pessoa via swift-evolution]

If we're to introduce the protected visibility, I think we should as well make 
it automatically internal or introduce an explicit protected internal 
visibility. I've been through many cases while programming in C# 'where' this 
was handy (thou I cannot name one from memory right now; it's been so many 
years ago...)



-Original Message-
From: "Xiaodi Wu via swift-evolution" 
Sent: ‎28/‎05/‎2016 08:10 PM
To: "Vanderlei Martinelli" ; "swift-evolution" 

Subject: Re: [swift-evolution] [Proposal] Protected Access Level

Seems entirely reasonable to me. POP aficionados may object, but I think the 
pros and cons of this type of access are well trodden terrain and I think it's 
a net win to have this available in Swift going forward.

On Sat, May 28, 2016 at 18:53 Vanderlei Martinelli via swift-evolution 
 wrote:

Hello.




This is the first draft. I'd like to know your opinion about it.


(I know that this subject could have been discussed before. If so, please 
indicate me the correct thread to follow and interact.)




Regards,


Vanderlei Martinelli




---




Introduction
Protected access level will enable entities to be used within the container 
type and by derived types only.
Motivation
Today Swift has three access levels (public, internal and private), but lacks a 
way to describe a member that can be only visible to its type or derived types.
A common case is the UIView from UIKit. Many developers are tempted to make 
this call:
view.layoutSubviews()The documentation says: "You should not call this method 
directly. If you want to force a layout update, call the setNeedsLayoutmethod 
instead to do so prior to the next drawing update. If you want to update the 
layout of your views immediately, call the layoutIfNeeded method."
But yes, you should call this method directly if you are subclassing the view 
and needs to perform additional layout to its subviews ("subclasses can 
override this method as needed"):
public override func layoutSubviews() {
// We are calling the super method directly here.
super.layoutSubviews()

// Do more adjustments to this view's subviews...
}So, yes, we can call this method directly when subclassing, but the Swift 
compiler will not prevent you from do this when not subclassing or from any 
other foreign class. It will not even issue a warning.
In Objective-C problems like this are usually "solved" my adding a kind of 
"protected" header (.h) that is intended to be included only when the developer 
is subclassing. In Swift we do not have headers, but we have the new access 
level model. So, if the declaration of this method was...
protected func layoutSubviews()... no one outside the class or derived classes 
would be allowed to call this method directly.
Of course, there are other cases in the Cocoa frameworks and there are many 
other cases when we are developing software in Swift that the protected access 
level would be very usefull.
Proposed solution
Create the protected access level.
Detailed design
Reference Types (classes)
When declarated by a class the protected member will be visible to the class 
itself and all the derived classes.
// BaseClass.swift
public class BaseClass {
public protected(set) var x = 20
protected let y = 10

protected func doSomething() {
// ...
}
}

// DerivedClass.swift
public class DerivedClass: BaseClass {
protected override doSomething() {
self.x = 10 * self.y
}
}If the member is declared as final then it will be visible but not can be 
overrided by the derived classes. Just like it works with other access levels.
Value Types (structs, enums, etc.)
Value types cannot have derived types. In this case the protected access level 
does not make sense and will not be allowed in their members.
Protocols
Protocols do not declare access level for their members. So the protected 
access level is not applicable here.
Extensions
Extensions will not be able do be protected nor their members.
Special Note
The protected access level can only be applied to classes, structs and other 
types when nested inside other type. So the following code will not compile:
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Enums with static storedpropertiesfor each case

[Leonardo Pessoa via swift-evolution]

So it should either be an exception when using tuples (which I know is not 
good) or ensure the combination of values in all tuple values are different 
from one another.



-Original Message-
From: "Jānis Kiršteins" 
Sent: ‎28/‎05/‎2016 03:58 PM
To: "Leonardo Pessoa" 
Cc: "Brent Royal-Gordon" ; "swift-evolution" 

Subject: Re: [swift-evolution] [Proposal] Enums with static storedpropertiesfor 
each case

As previosly state there is one problem using tuples as rawValues - they 
currently must be static (literals) and unique. In example with planets the 
mass or radius is not unique so it cannot be used as raw value with current 
requirments. 




On 28 May 2016, at 20:22, Leonardo Pessoa  wrote:


My suggestion of allowing tuples as raw values instead doesn't burden the 
language and also does not eliminate rawValue (treat previously supported raw 
value types as one value tuples), reads very cleanly and supports a syntax 
we're already familiar with. I don't see how the 'where' syntax reads like 
natural language and I agree it doesn't match other uses of where in the 
language.




From: Jānis Kiršteins via swift-evolution
Sent: ‎28/‎05/‎2016 10:54 AM
To: Brent Royal-Gordon
Cc: swift-evolution
Subject: Re: [swift-evolution] [Proposal] Enums with static stored 
propertiesfor each case


> - Abusing rawValue is just that: an abuse.

My original proposal does not replace rawValue and is compatible with it.

> - Using `where` just doesn't match the use of `where` elsewhere in the 
> language; everywhere else, it's some kind of condition.

It is also used in generic type constraints. Plus it reads like human
language: `case mercury where (mass: 3.303e+23, radius: 2.4397e6)`

> - Dictionaries are the most straightforward way to handle this with the 
> current language, but their lack of exhaustiveness checking is a problem.

Dictionaries can be used as workaround, but they cannot (lack of
exhaustiveness) solve the problem.

> What I would do is borrow the "accessors" concept from the property behaviors 
> proposal and extend it so that it supported both functions and variables.

Wouldn't accessor just be a redundant keyword here? Currently enums do
not support stored properties, so I guess there is no extra need to
mark properties with any special keyword.

Property accessors might work for enums with associated values, but
not so well without them.

On Fri, May 27, 2016 at 3:43 PM, Brent Royal-Gordon via
swift-evolution  wrote:
>> The suggested solution based on 'accessor' - will create assotiated 
>> properties each time the enum instace created, for each instance of enum 
>> type.
>
> No; property accessors would be either computed or constant (so that all 
> instances of a given case can share storage). This is much the way they would 
> behave if they were included in behaviors.
>
> You could write a property accessor with a setter, but it would have to be 
> computed, and manipulate `self`'s cases and associated values:
>
> enum Optional {
> accessor var unwrapped: T { get set }
>
> case none {
> unwrapped {
> get { fatalError("No value") }
> set { self = .some(newValue) }
> }
> }
> case some (_ value: T) {
> unwrapped {
> get { return value }
> set { self = .some(newValue) }
> }
> }
> }
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

My suggestion of allowing tuples as raw values instead doesn't burden the 
language and also does not eliminate rawValue (treat previously supported raw 
value types as one value tuples), reads very cleanly and supports a syntax 
we're already familiar with. I don't see how the 'where' syntax reads like 
natural language and I agree it doesn't match other uses of where in the 
language.



-Original Message-
From: "Jānis Kiršteins via swift-evolution" 
Sent: ‎28/‎05/‎2016 10:54 AM
To: "Brent Royal-Gordon" 
Cc: "swift-evolution" 
Subject: Re: [swift-evolution] [Proposal] Enums with static stored 
propertiesfor each case

> - Abusing rawValue is just that: an abuse.

My original proposal does not replace rawValue and is compatible with it.

> - Using `where` just doesn't match the use of `where` elsewhere in the 
> language; everywhere else, it's some kind of condition.

It is also used in generic type constraints. Plus it reads like human
language: `case mercury where (mass: 3.303e+23, radius: 2.4397e6)`

> - Dictionaries are the most straightforward way to handle this with the 
> current language, but their lack of exhaustiveness checking is a problem.

Dictionaries can be used as workaround, but they cannot (lack of
exhaustiveness) solve the problem.

> What I would do is borrow the "accessors" concept from the property behaviors 
> proposal and extend it so that it supported both functions and variables.

Wouldn't accessor just be a redundant keyword here? Currently enums do
not support stored properties, so I guess there is no extra need to
mark properties with any special keyword.

Property accessors might work for enums with associated values, but
not so well without them.

On Fri, May 27, 2016 at 3:43 PM, Brent Royal-Gordon via
swift-evolution  wrote:
>> The suggested solution based on 'accessor' - will create assotiated 
>> properties each time the enum instace created, for each instance of enum 
>> type.
>
> No; property accessors would be either computed or constant (so that all 
> instances of a given case can share storage). This is much the way they would 
> behave if they were included in behaviors.
>
> You could write a property accessor with a setter, but it would have to be 
> computed, and manipulate `self`'s cases and associated values:
>
> enum Optional {
> accessor var unwrapped: T { get set }
>
> case none {
> unwrapped {
> get { fatalError("No value") }
> set { self = .some(newValue) }
> }
> }
> case some (_ value: T) {
> unwrapped {
> get { return value }
> set { self = .some(newValue) }
> }
> }
> }
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

I agree. These are different proposals that can coexist but I think they should 
be evaluated separately by the community.



-Original Message-
From: "Vladimir.S via swift-evolution" 
Sent: ‎27/‎05/‎2016 08:05 AM
To: "Charles Srstka" 
Cc: "swift-evolution" 
Subject: Re: [swift-evolution] [Proposal] Enums with static stored 
propertiesfor each case

Correct me if I'm wrong, but this idea with accessors is not the same as 
static properties for each case. The one of ideas of initial proposal - 
static(!) values would be created only once and it is important in case it 
is expensive to create such value(or if should be created only once per case)

The suggested solution based on 'accessor' - will create assotiated 
properties each time the enum instace created, for each instance of enum type.

We can have something like the example with accessors now :

enum MyError: ErrorProtocol {
 struct MyErrorInfo {
 let localizedFailureReason: String
 let url: String
 }

 case fileNotFound(url: String)
 case fileIsCorrupt(url: String)

 var info : MyErrorInfo {
 switch self {
 case fileNotFound(let url) : return 
MyErrorInfo(localizedFailureReason: "File \"\(url.lowercased())\" not 
found.", url: url)

 case fileIsCorrupt(let url) : return 
MyErrorInfo(localizedFailureReason: "File \"\(url.lowercased())\"  is 
corrupt.", url: url)
 }
 }
}

var e = MyError.fileNotFound(url: "http://something.some;)
var info = e.info
print(info.localizedFailureReason, info.url)

But yes, such MyErrorInfo will be created on each `info.` call. This is 
worse that create MyErrorInfo once per each enum instance initialization, 
but IMO these solutions are close enough.

In any case, I don't see why tuple for enum and enum with `accessor` can 
not co-exists.

On 27.05.2016 2:28, Charles Srstka via swift-evolution wrote:
>> On May 26, 2016, at 4:47 PM, Brent Royal-Gordon via swift-evolution
>> > wrote:
>>
>> - Abusing rawValue is just that: an abuse.
>
> In addition, enums with associated types can’t have rawValues.
>
> Why is this relevant, you may ask? Because error enums are a huge use case
> for something like this. Being able to do the below would be great:
>
> enum MyError: ErrorProtocol {
> accessor var localizedFailureReason: String
> accessor var url: NSURL
>
> case FileNotFound(url: NSURL) {
> self.localizedFailureReason = “File \"\(url.lastPathComponent ??
> “”)\” not found.”
> self.url = url
> }
>
> case FileIsCorrupt(url: NSURL) {
> self.localizedFailureReason = “File \"\(url.lastPathComponent ??
> “”)\” is corrupt.”
> self.url = url
> }
> }
>
> This would be much cleaner than the existing method of using a switch to
> create a userInfo dictionary for creating an NSError to send to
> -[NSApplication presentError:] and similar methods.
>
> Charles
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Property reflection

[Leonardo Pessoa via swift-evolution]

I'm also not fond of allowing what could be called a backdoor to accessing 
privates and intervals too but has anyone thought of enhancing the Mirror class 
instead of having something totally new? I've tried using it once but in the 
end it wasn't necessary for what I needed to do.

An opt-in into reflection would be interesting too as it could help remove the 
burden of the compiler to prepare each class and instance for reflection. 
Should a type be prepared for reflection one could add to it an attribute like 
@reflected. Then the compiler would add the necessary optimisations to it and 
its subclasses.

About serialisation, I still think the best way to deal with it is to use the 
Visitor pattern. Each class that needs serialisation implements the functions 
that say what exactly is needed to save and restore state. I don't see how 
anything automatic can be better than this.


-Original Message-
From: "Brent Royal-Gordon via swift-evolution" 
Sent: ‎27/‎05/‎2016 07:25 AM
To: "Matthew Johnson" 
Cc: "swift-evolution" 
Subject: Re: [swift-evolution] [Pitch] Property reflection

> This one is tricky.  I am generally be opposed to any way to get around 
> access control.  But people are going to implement things like serialization 
> using this which may require access to private properties.  I think we want 
> to try to understand the consequences of different options and when in doubt 
> decide in favor caution.

I had some thoughts about an alternate design based partially on access control 
concerns. Sketching roughly, it looks like this:

* There is a pseudo-property called, say, `properties` on every type (and 
perhaps on every instance). (Alternate designs are available, like an 
`inout`-returning pseudo-function. It doesn't really matter.)

* `properties` is a dictionary, or at least something very like a dictionary: 
you can look something up by key or iterate over the available keys. Its keys 
are strings, and its values are lens functions. These lens functions return 
type Any; their setters throw if you assign an incompatible type.

* The contents of `properties` are the properties visible *at the site where it 
is called*. That means calling `properties` in different places will give you 
different results. If you import a type from another module and then add 
properties in an `internal` extension, you'll see the other module's `public` 
properties plus your `internal` ones.

* You can pass your `properties` dictionary to other code; that effectively 
delegates your access to that other code. Thus, if your main class body passes 
its `property` dictionary to a serialization library, that library can access 
your private properties. If you pass it `inout`, then the library can modify 
your private properties.

* There is no opting in, but I *think* the compiler has enough information to 
figure out what goes into `properties` at the sites where it is used, so you 
only have to pay for it if and when you use it. I could be wrong, though—there 
may be something there that I'm missing.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Enums with staticstoredpropertiesforeach case

[Leonardo Pessoa via swift-evolution]

Ok, I'm not familiar with Scala but if the language does not have support for 
the type of enums we're discussing it may be their chosen mechanism to handle 
enums with associated values (feel free to correct me if I'm wrong always) but 
my main point for enums is still: do we really need to introduce another 
concept to handle the presented examples or can we reuse an existing concept? 
Enums are (or can be seen as) our case classes but there seems to exist a need 
for enums to hold more than just one value as of today.

Just to mention ahead, I'm not in favour of enum values having methods or 
computed properties



-Original Message-
From: "Charlie Monroe" 
Sent: ‎26/‎05/‎2016 04:57 PM
To: "Leonardo Pessoa" 
Cc: "Vladimir.S" ; "swift-evolution" 

Subject: Re: [swift-evolution] [Proposal] Enums with 
staticstoredpropertiesforeach case

Not really. When you take Scala's case classes, they are exactly for this 
purpose:


http://docs.scala-lang.org/tutorials/tour/case-classes.html


abstract class Term

case class Var(name: String) extends Term

case class Fun(arg: String, body: Term) extends Term

case class App(f: Term, v: Term) extends Term



Which in Swift could be an enum.


You can look at sealed classes in two ways:


1) Something that prevents others from subclassing your classes.
2) Something that ensures that only a known number of subclasses exists at 
compile-time - which is pretty much the definition of an enum.






On May 26, 2016, at 9:48 PM, Leonardo Pessoa  wrote:


I think these are different concepts. Classes and structs are abstractions for 
something (think of them as empty forms while instances are filled forms) while 
enums identify a closed set of values (filled forms) known ahead of use. Sealed 
classes are intended to limit extensions to a class not to the instances that 
can be created.




From: Charlie Monroe
Sent: ‎26/‎05/‎2016 03:13 PM
To: Vladimir.S
Cc: Leonardo Pessoa; swift-evolution
Subject: Re: [swift-evolution] [Proposal] Enums with static 
storedpropertiesforeach case


Now thinking about this, what would solve this partially is being discussed in 
another topic here - sealed clasees.

Each planet would have its own class and the superclass Planet would be 
abstract sealed. You would then be able to do an effective switch on the 
instance of the planet, which would act like an enum.

> On May 26, 2016, at 8:06 PM, Vladimir.S via swift-evolution 
>  wrote:
> 
> Yes, this was mentioned in a similar thread in this email list earlier. There 
> is even some proposal for such .values() for Swift enums.
> 
> But this values() in Java is not the same thing as discussed dictionary with 
> *keys* of enum type or Delphi's arrays with *index* of enum type.
> 
> Could you write Java's example for array/dictionary of String which 
> *index*(or key) will be of enum type? *And* compiler will check that value 
> for each enum case is set in case of array of constants like:
> MyConsts : array [TMyEnum] of String = ('just one', 'two here')
> // compiler will always check that value assigned for each case
> 
> 
> On 26.05.2016 20:58, Leonardo Pessoa wrote:
>> Java enums automatically have a static values() method that return an array
>> with all values in an enum.
>> ---
>> From: Vladimir.S via swift-evolution 
>> Sent: ‎26/‎05/‎2016 02:36 PM
>> To: Ross O'Brien 
>> Cc: swift-evolution 
>> Subject: Re: [swift-evolution] [Proposal] Enums with static stored
>> propertiesforeach case
>> 
>> On 26.05.2016 19:50, Ross O'Brien wrote:
>>> Perhaps there's an argument to be made for a sort of 'enumDictionary' type
>>> - a dictionary whose keys are all the cases of an enum, and is thus
>>> guaranteed to produce a value.
>> 
>> In Delphi(Pascal) you can define an array with indexes of enum type i.e.:
>> type
>>   TMyEnum = (One, Two)
>> var
>>   MyVal : array[TMyEnum] of String
>> const
>>   MyConsts : array [TMyEnum] of String = ('just one', 'two here')
>>   // compiler will check that values for each enum were specified here
>> 
>> ,so you can do
>> var e: TMyEnum
>> e := One;
>> MyVal[e] := 'hello';
>> s2 := MyConsts[e];
>> 
>> This is really useful and used a lot. And this is safe in meaning compiler
>> will notify you if you changed the enum - you'll have to change such
>> constant array.
>> 
>> I wish we'll have something like this in Swift.
>> 
>>> 
>>> I think the question I have is how you'd access the values, syntactically.
>>> To use the Planet example, if '.earth' is a value of the Planet enum, is
>>> '.earth.mass' an acceptable way to access its mass? Or perhaps
>>> 'Planet[.earth].mass'?
>> 
>> Just like .rawValue currently, i.e.
>> let e = Planet.earth
>> 

Re: [swift-evolution] [Proposal] Enums with static storedpropertiesforeach case

[Leonardo Pessoa via swift-evolution]

gt; ...
>>
>> }
>>
>> So that you assign the additional information to the enum
>> value itself.
>>
>> Charlie
>>
>>
>>
>> On 26 May 2016, at 1:47 PM, David Sweeris via
>> swift-evolution
>> <swift-evolution@swift.org
>> <mailto:swift-evolution@swift.org>
>> <mailto:swift-evolution@swift.org
>> <mailto:swift-evolution@swift.org>>> wrote:
>>
>>
>> On May 25, 2016, at 10:27 PM, Jacob
>> Bandes-Storch <jtban...@gmail.com
>> <mailto:jtban...@gmail.com>
>> <mailto:jtban...@gmail.com
>> <mailto:jtban...@gmail.com>>> wrote:
>>
>> On Wed, May 25, 2016 at 8:15 PM, David Sweeris
>> via swift-evolution
>> <swift-evolution@swift.org
>> <mailto:swift-evolution@swift.org>
>> <mailto:swift-evolution@swift.org
>> <mailto:swift-evolution@swift.org>>> wrote:
>>
>> On May 25, 2016, at 7:37 AM, Leonardo
>> Pessoa via swift-evolution
>> <swift-evolution@swift.org
>> <mailto:swift-evolution@swift.org>
>> <mailto:swift-evolution@swift.org
>> <mailto:swift-evolution@swift.org>>>
>> wrote:
>>
>>
>>
>> Hi,
>>
>> Couldn't this be solved by using
>> tuples? If not because the syntax
>> is not allowed I think this would be
>> more coherent to do it using
>> current syntax.
>>
>> enum Planet : (mass: Float, radius:
>> Float) {
>> case mercury = (mass: 3.303e+23,
>> radius: 2.4397e6)
>> case venus = (mass: 4.869e+24,
>> radius: 6.0518e6)
>> case earth = (mass: 5.976e+24,
>> radius: 6.37814e6)
>> case mars = (mass: 6.421e+23,
>> radius: 3.3972e6)
>> case jupiter = (mass: 1.9e+27,
>> radius: 7.1492e7)
>> case saturn = (mass: 5.688e+26,
>> radius: 6.0268e7)
>> case uranus = (mass: 8.686e+25,
>> radius: 2.5559e7)
>> case neptune = (mass: 1.024e+26,
>> radius: 2.4746e7)
>> }
>>
>>
>>
>> This would be my preferred solution… AFAIK,
>> the only reason we
>> can’t do it now is that Swift currently
>> requires RawValue be an
>> integer, floating-point value, or string. I
>> don’t know why the
>> language has this restriction, so I can’t
>> comment on how hard it
>> would be to change.
>>
>> - Dave Sweeris
>>
>>
>> Except you'd have to write
>> Planet.mercury.rawValue.mass, rather than
>> Planet.mercury.mass.
>>
>> This could be one or two proposals: allow enums
>> with tuple RawValues,
>> and allow `TupleName.caseName.propertyName` to
>>

Re: [swift-evolution] [Proposal] Enums with static stored propertiesforeach case

[Leonardo Pessoa via swift-evolution]

anet.moon
> print(m, m.info.description)
>
>
>
> On 26.05.2016 8:26, Charlie Monroe via swift-evolution wrote:
>
>
> What this proposal is asking for is an easier way to
> have derived values
> from enum cases. Asking for more flexible RawValues
> means mass and radius
> are not derived, they are the source of truth. It goes
> against the whole
> point of RawRepresentable. You are not saying ‘Mercury
> is identified by
> the case .mercury’, you are saying ‘Mercury is
> identified by a mass of
> 3.303e+23’. It’s backwards.
>
>
>
> I see what Janis meant in the first email. It's not that
> the planet would
> be identified by the mass or radius. It could very much be
>
> case Mercury = 1 where (mass: 3, radius: 2),
>
> - Mercury's rawValue would be 1.
>
> The issue here is that sometimes you want additional
> information with the
> enum. There are many cases where you extend the enum with a
> variable:
>
> enum Error {
> case NoError
> case FileNotFound
> ...
>
> var isFatal: Bool {
> /// swtich over all values of self goes here.
> }
>
> var isNetworkError: Bool {
> /// swtich over all values of self goes here.
> }
>
> var isIOError: Bool {
> /// swtich over all values of self goes here.
> }
> }
>
> What the propsal suggests is to simplify this to the 
> following:
>
> enum Error {
> var isFatal: Bool
>
> case NoError where (isFatal: false, isNetworkError: false,
> isIOError:
> false)
> case FileNotFound  where (isFatal: true, isNetworkError:
> false, isIOError:
> true)
> ...
>
> }
>
> So that you assign the additional information to the enum
> value itself.
>
> Charlie
>
>
>
> On 26 May 2016, at 1:47 PM, David Sweeris via
> swift-evolution
> <swift-evolution@swift.org
> <mailto:swift-evolution@swift.org>
> <mailto:swift-evolution@swift.org
> <mailto:swift-evolution@swift.org>>> wrote:
>
>
> On May 25, 2016, at 10:27 PM, Jacob
>             Bandes-Storch <jtban...@gmail.com
> <mailto:jtban...@gmail.com>
> <mailto:jtban...@gmail.com
> <mailto:jtban...@gmail.com>>> wrote:
>
> On Wed, May 25, 2016 at 8:15 PM, David Sweeris
> via swift-evolution
> <swift-evolution@swift.org
> <mailto:swift-evolution@swift.org>
> <mailto:swift-evolution@swift.org
> <mailto:swift-evolution@swift.org>>> wrote:
>
> On May 25, 2016, at 7:37 AM, Leonardo
> Pessoa via swift-evolution
> <swift-evolution@swift.org
> <mailto:swift-evolution@swift.org>
> <mailto:swift-evolution@swift.org
> <mailto:swift-evolution@swift.org>>>
> wrote:
>
>
>
> Hi,
>
> Couldn't this be solved by using
> tuples? If not because the syntax
> is not allowed I think this would be
> more coherent to do it using
> current syntax.
>
> enum Planet : (mass: Float, radius:
> Float) {
> case mercury = (mass: 3.303e+23,
>

Re: [swift-evolution] [Proposal] Enums with static stored propertiesforeach case

[Leonardo Pessoa via swift-evolution]

That caseName I'd the solution I miss and would like to see. Indeed when I see 
an enum the name is the reference to whatever value it should be holding. Think 
of this:

// all relative to Earth's mass, I'm not digging the real values now 
enum Mass : Float {
   case Earth = 1.0
   case Moon = 0.2
   ...
}

Since the values of each case are what's serialised, should I change the values 
here to absolute values I'm unable to deserialise the stored values because the 
values no longer exist.

IMO enums are a language resource used to mask values by a name just like a 
group of related constants. Being able to find an enum value by its raw value 
is a good way to convert the value into an enum but you should not rely on it 
to ever hold the same value forever so yes enum names are supposed to be the 
truth but that's just not how it works in Swift (still, I do love being able to 
parameterise enum cases, so I'm not suggesting to remove them).

As for having to use rawValue, we could work out a solution that would allow 
direct use of the properties in the tuple and I already have an idea: to make 
this:

enum Mass : Float {
   case Earth = 1.0
   case Moon = 0.2
}

be a shortcut in the language that is internally transformed and handled like 
this by the compiler:

enum Mass : (rawValue: Float) {
   case Earth = (rawValue : 1.0)
   case Moon = (rawValue: 0.2)
}

This doesn't break the current syntax of typed enums and still would allow us 
to access Planet.mercury.mass (in the previous examples) directly without using 
rawValue in the middle.

What do you think?



-Original Message-
From: "Jānis Kiršteins via swift-evolution" <swift-evolution@swift.org>
Sent: ‎26/‎05/‎2016 02:59 AM
To: "Charlie Monroe" <char...@charliemonroe.net>
Cc: "swift-evolution" <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Proposal] Enums with static stored 
propertiesforeach case

The argument against giving away raw value is that it grants
uniqueness of cases when serialized. One can reliably do:

// serialize
let rawValue = Planet.mercury.rawValue

// and de-serialize
guard let planet = Planet(rawValue: rawValue) else {
// ...
}

Currently raw values cannot only be equatables that are also literals
so their uniqueness can be checked at compile time. An alternative
could be that you can serialize/deserialize by case name. For example:

// serialize
let caseName = Planet.mercury.caseName // "mercury"

// de-serialize
guard let planet = Planet(caseName: "mercury") else {
// ...
}

On Thu, May 26, 2016 at 8:26 AM, Charlie Monroe via swift-evolution
<swift-evolution@swift.org> wrote:
> What this proposal is asking for is an easier way to have derived values
> from enum cases. Asking for more flexible RawValues means mass and radius
> are not derived, they are the source of truth. It goes against the whole
> point of RawRepresentable. You are not saying ‘Mercury is identified by the
> case .mercury’, you are saying ‘Mercury is identified by a mass of
> 3.303e+23’. It’s backwards.
>
>
> I see what Janis meant in the first email. It's not that the planet would be
> identified by the mass or radius. It could very much be
>
> case Mercury = 1 where (mass: 3, radius: 2),
>
> - Mercury's rawValue would be 1.
>
> The issue here is that sometimes you want additional information with the
> enum. There are many cases where you extend the enum with a variable:
>
> enum Error {
> case NoError
> case FileNotFound
> ...
>
> var isFatal: Bool {
> /// swtich over all values of self goes here.
> }
>
> var isNetworkError: Bool {
> /// swtich over all values of self goes here.
> }
>
> var isIOError: Bool {
> /// swtich over all values of self goes here.
> }
> }
>
> What the propsal suggests is to simplify this to the following:
>
> enum Error {
> var isFatal: Bool
>
> case NoError where (isFatal: false, isNetworkError: false, isIOError: false)
> case FileNotFound  where (isFatal: true, isNetworkError: false, isIOError:
> true)
> ...
>
> }
>
> So that you assign the additional information to the enum value itself.
>
> Charlie
>
>
>
> On 26 May 2016, at 1:47 PM, David Sweeris via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
> On May 25, 2016, at 10:27 PM, Jacob Bandes-Storch <jtban...@gmail.com>
> wrote:
>
> On Wed, May 25, 2016 at 8:15 PM, David Sweeris via swift-evolution
> <swift-evolution@swift.org> wrote:
>>
>> On May 25, 2016, at 7:37 AM, Leonardo Pessoa via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>>
>> Hi,
>>
>> Couldn't this be solved by using tuples? If not because the syntax is not
>> allowed I think this would be more coherent to do it using current syntax.
>

Re: [swift-evolution] [Proposal] Enums with static stored propertiesforeach case

[Leonardo Pessoa via swift-evolution]

I'd still go with tuple syntax as it feels more like a natural extension to 
current enum syntax and does not introduce new elements to the syntax of enums 
(other than add tuples as a possible enum value type) thus being simpler and 
faster to implement and learn than a new syntax built specifically for this 
kind of construction.

As I mentioned before, the issue with JSON and other engines trying to record 
the raw value instead of the enum seems to me as a wrong implementation choice 
of the engine. Previous to Swift enums I've always seen enum cases the same as 
constants and any additional values they'd hold are associated with that 
constant and not persisted. This may also be a thing from the company I work 
for today that choses to store the names of the enum cases (as strings) in 
databases and any values associated with them are recovered from the enum case 
constant. Of course the language I work with supports finding the enum value by 
its name, which it seems Swift doesn't.



-Original Message-
From: "Patrick Smith" 
Sent: ‎25/‎05/‎2016 10:20 PM
To: "Jānis Kiršteins" 
Cc: "Leonardo Pessoa" ; "swift-evolution@swift.org" 

Subject: Re: [swift-evolution] [Proposal] Enums with static stored 
propertiesforeach case

Yes, I don’t think it would work with a raw value behaviour. You want it to 
compile down to the same underlying code as the first example, without having 
to write lots of switch statements.

Another syntax I could imagine is:

enum Planet {
  var mass: Float { get }
  var radius: Float { get }

  case mercury [
mass: 3.303e+23,
radius: 2.4397e6
  ]
  case venus [
mass: 4.869e+24,
radius: 6.0518e6
  ]
  case earth [
mass: 5.976e+24,
radius: 6.37814e6
  ]
  ...
}


You couldn’t have an initializer, as enums only have storage when they have 
associated values, which these do not. ‘where’ is used for pattern matching, 
not declaring as far as I know, so that’s why I suggest this other way.

Patrick

> On 26 May 2016, at 5:50 AM, Jānis Kiršteins via swift-evolution 
>  wrote:
> 
> That would replace current enum raw value functionality and I see two
> problems with that.
> 
> 1. A lot of breaking changes
> 2. Raw values currently are unique values among all cases. That makes
> a possibility that enums can be easily serialized/deserialized to
> formats like JSON, property lists, etc. In "case mercury = (mass:
> 3.303e+23, radius: 2.4397e6)" neither mass nor radius is unique value
> (it is possible that two different planets could have the same mass as
> radius).
> 
> 
> 
> On Wed, May 25, 2016 at 3:37 PM, Leonardo Pessoa  wrote:
>> Hi,
>> 
>> Couldn't this be solved by using tuples? If not because the syntax is not
>> allowed I think this would be more coherent to do it using current syntax.
>> 
>> enum Planet : (mass: Float, radius: Float) {
>>case mercury = (mass: 3.303e+23, radius: 2.4397e6)
>>case venus = (mass: 4.869e+24, radius: 6.0518e6)
>>case earth = (mass: 5.976e+24, radius: 6.37814e6)
>>case mars = (mass: 6.421e+23, radius: 3.3972e6)
>>case jupiter = (mass: 1.9e+27, radius: 7.1492e7)
>>case saturn = (mass: 5.688e+26, radius: 6.0268e7)
>>case uranus = (mass: 8.686e+25, radius: 2.5559e7)
>>case neptune = (mass: 1.024e+26, radius: 2.4746e7)
>> }
>> 
>> From: Jānis Kiršteins via swift-evolution
>> Sent: ‎25/‎05/‎2016 08:58 AM
>> To: swift-evolution@swift.org
>> Subject: [swift-evolution] [Proposal] Enums with static stored properties
>> foreach case
>> 
>> Hello everyone,
>> 
>> Currently Swift only supports computed properties for each enum case.
>> If you want to somehow get static values with each case you would
>> probably do it like this:
>> 
>> enum Planet {
>>case mercury
>>case venus
>>case earth
>>case mars
>>case jupiter
>>case saturn
>>case uranus
>>case neptune
>> 
>>var mass: Float {
>>switch self {
>>case .mercury: return 3.303e+23
>>case .venus: return 4.869e+24
>>case .earth: return 5.976e+24
>>case .mars: return 6.421e+23
>>case .jupiter: return 1.9e+27
>>case .saturn: return 5.688e+26
>>case .uranus: return 8.686e+25
>>case .neptune: return 1.024e+26
>>}
>>}
>> 
>>var radius: Float {
>>switch self {
>>case .mercury: return 2.4397e6
>>case .venus: return 6.0518e6
>>case .earth: return 6.37814e6
>>case .mars: return 3.3972e6
>>case .jupiter: return 7.1492e7
>>case .saturn: return 6.0268e7
>>case .uranus: return 2.5559e7
>>case .neptune: return 2.4746e7
>>}
>>}
>> }
>> 
>> However I see two problems with this approach:
>> 
>> 1. These value definitions are spread out and difficult to read and
>> maintain (especially if you have 

Re: [swift-evolution] [Pitch] Remove associated type inference

[Leonardo Pessoa via swift-evolution]

-1. I don't really see how this is a bad thing and why it has to change. To me 
this is one of the best features of the language and I want more of it (I've 
been through some situations it was totally obvious the expected type of a 
variable and the compiler couldn't infer it) not less.



-Original Message-
From: "Matthew Johnson via swift-evolution" 
Sent: ‎25/‎05/‎2016 07:06 PM
To: "David Hart" 
Cc: "Swift-evolution" 
Subject: Re: [swift-evolution] [Pitch] Remove associated type inference

I agree that if we’re going to do it we should probably do it in Swift 3.  But 
it is a very convenient and useful feature that significantly lowers the bar of 
conforming to protocols with associated types (in many cases you can just 
implement the required members without thinking about the associated types).  I 
think we should have a more detailed and compelling story about why we’re 
considering this change than I see in this proposal.


Are there any benefits users might receive from this change (assuming type 
checker architecture and bugs could eventually be ironed out)?  Is it actively 
blocking desirable new features?  If so what are they and in what way are they 
blocked?




On May 25, 2016, at 4:43 PM, David Hart via swift-evolution 
 wrote:


Here’s a pitch for removing associated type inference as per the Generics 
Manifesto. If we want to do it, we’d better do it before Swift 3:


Remove associated type inference
Proposal: SE-
Author: David Hart, Douglas Gregor
Status: TBD
Review manager: TBD
Introduction
This proposal seeks to remove the inference of associated types in types 
conforming to protocols.
Motivation
Even if associated types inference in a useful feature, it is also a big source 
of bugs in the compiler. This proposal argues that the usefulness does not 
outweight its architectural complexity. As per the Generics Manifesto:
associated type inference is the only place in Swift where we have a global 
type inference problem: it has historically been a major source of bugs, and 
implementing it fully and correctly requires a drastically different 
architecture to the type checker.
Because this is a breaking change, it would be beneficial to implement it for 
Swift 3. 
Detailed Design
The proposal would remove associated type inference and make code which relied 
on it invalid:
protocol IteratorProtocol {
  associatedtype Element
  mutating func next() -> Element?
}

struct IntIterator : IteratorProtocol {
  mutating func next() -> Int? { ... }  // used to infer Element = Int
}The compiler would generate an error message stating: error: IntIterator is 
missing its Element associated type declaration. The code would have to be 
modified as follows to fix the error:
struct IntIterator : IteratorProtocol {
typealias Element = Int
mutating func next() -> Int? { return nil }  // used to infer Element = Int
}Impact on Existing Code
This is a breaking change that will require conforming types which relied on 
the inference, including in the Standard Library, to explicitly declare 
associated types. A Fix-It could be introduced to add the typealias and leave 
the type to be filled in. That way, all the type inference could be removed 
from the compiler.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

[Leonardo Pessoa via swift-evolution]

I get it that the point here is about the intention. If you mean to call
that initialiser, using an extra name or none should make no difference. If
there is a chance people are misusing the nameless initialiser, I don't see
a reason why not adding a name here.

On Wednesday, 25 May 2016, Karl Wagner via swift-evolution <
swift-evolution@swift.org> wrote:

> What is so bad about the global function idea?
>
> reflect(_:Any)->String
>
> It’s invoking the reflection APIs, doing a bunch of things you could do
> yourself with Mirror, and returning a String.
>
> I know we don’t have many global functions, but this seems like a
> reasonable place for one.
>
> This isn’t Objective-C; we have namespaces. You can still create another
> function with that same signature, and refer to the global one with
> Swift.reflect().
>
> Karl
>
> > On 22 May 2016, at 20:19, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org > wrote:
> >
> >
> > on Fri May 20 2016, Kevin Ballard  > wrote:
> >
> >> On Fri, May 20, 2016, at 05:14 PM, Dave Abrahams via swift-evolution
> wrote:
> >>>
> >>> on Fri May 20 2016, Kevin Ballard  > wrote:
> >>>
>  On Tue, May 17, 2016, at 08:32 PM, Chris Lattner via swift-evolution
> wrote:
> >   * What is your evaluation of the proposal?
> >>
> 
>  I'm a little nervous about this change, because converting things to
>  strings is a fairly basic operation and it should be immediately
>  obvious how to do that. That said, the described issues are pretty
>  bad, and I know I've had to carefully triple-check sometimes to make
>  sure I was calling the right initializer. So I'm +1 on the idea.
> 
>  That said, I don't like the name String(printing:). As others have
>  pointed out, it sounds like this is related to print(), but this
>  initializer does not actually print anything, it just converts any
>  value into a string. I also don't like String(describing:) because
>  it's too long. This initializer should be easier to call than
>  String(reflecting:). Also, in my experience this initializer is
>  particularly useful with code of the form `someOpt.map(String.init)`,
>  and saying `someOpt.map(String.init(describing:))` is annoyingly long.
> 
>  Given this, I'd like to suggest the simpler `String(from:)`. It's
>  short and generic, and it makes sense as it creates a String from any
>  value.
> >>>
> >>> Not too bad.  I could live with it.
> >>
> >> 
> >>
>  I'm also not a fan of Dave's suggestion of removing this initializer
>  entirely in favor of "\(foo)".  This feels weird, and it also can't be
>  turned into a first-class function value.
> >>>
> >>>  { "\($0)" }
> >>>
> >>> ?
> >>
> >> Good point. I think what I intended to express was you cannot refer to
> >> this operation by name anymore. Maybe not a big deal, but it feels
> >> weird.
> >
> > Makes sense.
> >
> > --
> > -Dave
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org 
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


--
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove associated type inference

[Leonardo Pessoa via swift-evolution]

On Wednesday, 25 May 2016, Dmitri Gribenko via swift-evolution <
swift-evolution@swift.org> wrote:

> On Wed, May 25, 2016 at 2:52 PM, David Hart  > wrote:
> >
> >> On 25 May 2016, at 23:47, Dmitri Gribenko  > wrote:
> >>
> >> On Wed, May 25, 2016 at 2:43 PM, David Hart via swift-evolution
> >> > wrote:
> >>> Impact on Existing Code
> >>>
> >>> This is a breaking change that will require conforming types which
> relied on
> >>> the inference, including in the Standard Library, to explicitly declare
> >>> associated types. A Fix-It could be introduced to add the typealias and
> >>> leave the type to be filled in. That way, all the type inference could
> be
> >>> removed from the compiler.
> >>
> >> Please show an example -- for example, what a smallest collection type
> >> will look like.
> >
> > Isn’t that the example in the Detailed Design section? What other
> example were you thinking of?
>
> You are showing an iterator.  Try doing a collection, it has many more
> associated types most of which are defaulted.
>
> >>> Alternatives Considered
> >>>
> >>> The only alternative is to keep the inference with the known
> consequences on
> >>> the compiler.
> >>
> >> Sorry, that's not fair :)  There is a middle ground -- limited
> >> inference.  For example, in Collection, we don't need Index to be
> >> inferrable from every declaration that mentions it.  We can add a
> >> feature to declare that the type of 'var startIndex' infers
> >> 'associatedtype Index' (via an appropriate attribute).  It is true
> >> that this approach would not remove global inference as such, but it
> >> will make it a much easier problem I believe.
> >
> > This sounds like a more complicated solution: it does not remove global
> inference and complicates the language with an additional attribute only to
> help the compiler. I don’t see many advantages to this solution.
>
> The advantage is that we can keep the boilerplate down, and make the
> problem easier in the compiler.


If the issue is easing the work of the compiler, are you suggesting
dropping the entire type inference? I don't really think removing it here
will "solve" anything.


>
> Dmitri
>
> --
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko  >*/
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


--
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Enums with static stored propertiesforeach case

[Leonardo Pessoa via swift-evolution]

But that's an issue related to how serialising JSON works. Should the API 
serialise the name of the value and not the associated values, it should work 
fine. Should we have anything like annotations in Swift to describe how we 
wanted that output we'd have no problems.

About breaking things I wouldn't worry as Swift 3 is going to break a lot by 
itself anyway.



-Original Message-
From: "Jānis Kiršteins" 
Sent: ‎25/‎05/‎2016 04:50 PM
To: "Leonardo Pessoa" 
Cc: "swift-evolution@swift.org" 
Subject: Re: [swift-evolution] [Proposal] Enums with static stored 
propertiesforeach case

That would replace current enum raw value functionality and I see two
problems with that.

1. A lot of breaking changes
2. Raw values currently are unique values among all cases. That makes
a possibility that enums can be easily serialized/deserialized to
formats like JSON, property lists, etc. In "case mercury = (mass:
3.303e+23, radius: 2.4397e6)" neither mass nor radius is unique value
(it is possible that two different planets could have the same mass as
radius).



On Wed, May 25, 2016 at 3:37 PM, Leonardo Pessoa  wrote:
> Hi,
>
> Couldn't this be solved by using tuples? If not because the syntax is not
> allowed I think this would be more coherent to do it using current syntax.
>
> enum Planet : (mass: Float, radius: Float) {
> case mercury = (mass: 3.303e+23, radius: 2.4397e6)
> case venus = (mass: 4.869e+24, radius: 6.0518e6)
> case earth = (mass: 5.976e+24, radius: 6.37814e6)
> case mars = (mass: 6.421e+23, radius: 3.3972e6)
> case jupiter = (mass: 1.9e+27, radius: 7.1492e7)
> case saturn = (mass: 5.688e+26, radius: 6.0268e7)
> case uranus = (mass: 8.686e+25, radius: 2.5559e7)
> case neptune = (mass: 1.024e+26, radius: 2.4746e7)
> }
> 
> From: Jānis Kiršteins via swift-evolution
> Sent: ‎25/‎05/‎2016 08:58 AM
> To: swift-evolution@swift.org
> Subject: [swift-evolution] [Proposal] Enums with static stored properties
> foreach case
>
> Hello everyone,
>
> Currently Swift only supports computed properties for each enum case.
> If you want to somehow get static values with each case you would
> probably do it like this:
>
> enum Planet {
> case mercury
> case venus
> case earth
> case mars
> case jupiter
> case saturn
> case uranus
> case neptune
>
> var mass: Float {
> switch self {
> case .mercury: return 3.303e+23
> case .venus: return 4.869e+24
> case .earth: return 5.976e+24
> case .mars: return 6.421e+23
> case .jupiter: return 1.9e+27
> case .saturn: return 5.688e+26
> case .uranus: return 8.686e+25
> case .neptune: return 1.024e+26
> }
> }
>
> var radius: Float {
> switch self {
> case .mercury: return 2.4397e6
> case .venus: return 6.0518e6
> case .earth: return 6.37814e6
> case .mars: return 3.3972e6
> case .jupiter: return 7.1492e7
> case .saturn: return 6.0268e7
> case .uranus: return 2.5559e7
> case .neptune: return 2.4746e7
> }
> }
> }
>
> However I see two problems with this approach:
>
> 1. These value definitions are spread out and difficult to read and
> maintain (especially if you have many computed properties for each
> enum case);
> 2. These values are not static. They are computed each time property
> is accessed. This can be a problem when value is expensive to create.
>
> The proposed solution is to have single static initializer for each
> enum case that initializes stored properties. For example,
>
> enum Planet {
> var mass: Float
> var radius: Float
>
> static init(mass: Float, radius: Float) {
> self.mass = mass
> self.radius = radius
> }
>
> case mercury where (mass: 3.303e+23, radius: 2.4397e6)
> case venus where (mass: 4.869e+24, radius: 6.0518e6)
> case earth where (mass: 5.976e+24, radius: 6.37814e6)
> case mars where (mass: 6.421e+23, radius: 3.3972e6)
> case jupiter where (mass: 1.9e+27, radius: 7.1492e7)
> case saturn where (mass: 5.688e+26, radius: 6.0268e7)
> case uranus where (mass: 8.686e+25, radius: 2.5559e7)
> case neptune where (mass: 1.024e+26, radius: 2.4746e7)
> }
>
> This approach do not affect enums that have raw or associated values,
> or custom enum initializers:
>
> case A = "A" where (id: 0)
>
> or
>
> case B(Int, Int, Int) where (id: 0)
>
> Benefits:
> 1. Less verbosity
> 2. Improved readability
> 3. Related values are closer to each other
> 4. Static values are not recomputed
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list

Re: [swift-evolution] [Pitch] Exhaustive pattern matching forprotocols and classes

[Leonardo Pessoa via swift-evolution]

I like the idea of sealed types but I think much better is Ceylon's concept of 
previously declaring the many subclasses that are going to exist both because I 
can have a bunch of public classes in a framework and restrict their subclasses 
and because there are threads in this group discussing the idea of a union type 
(perhaps both ideas could benefit from one another).

Another idea could be to add a single simple keyword to the root class (could 
even be sealed but I don't think it grabs this concept) to declare all its 
subclasses must exist within the same module. That would restrict the number of 
subclasses to the compiler without requiring us to revisit the root class each 
time we need to create a subclass and would still allow for every subclass to 
be public.

Sealed wouldn't be a good idea because the root class would still enable 
subclassing and it would be ideal that the switch could only work with these 
"sealed" types.

+1 for enabling this for protocols too.

Just a few issues: 
- here we're considering having subclasses of subclasses, or not? 
-what about public protocols being adopted outside the module, should we just 
ignore them or completely forbid the adoption?



-Original Message-
From: "Thorsten Seitz via swift-evolution" 
Sent: ‎25/‎05/‎2016 01:18 PM
To: "Thorsten Seitz" 
Cc: "swift-evolution" 
Subject: Re: [swift-evolution] [Pitch] Exhaustive pattern matching forprotocols 
and classes

Just realized that Matthew did introduce `sealed` exactly to enable this for 
public types. That's fine with me!


-Thorsten 

Am 25.05.2016 um 18:11 schrieb Thorsten Seitz via swift-evolution 
:


Ceylon uses the following syntax for stating that a class has a finite set of 
subclasses:


class C of C1 | C2 {...}


where `|` is the type union operator. Swift could use a simple comma separated 
list instead after the `or`. The advantage over sealed+private/internal would 
be thatnthe class or protocol could be public as well.


-Thorsten 

Am 25.05.2016 um 04:01 schrieb David Sweeris via swift-evolution 
:


Or if there was a way to declare that a class/protocol can only have a defined 
set of subclasses/conforming types.

Sent from my iPhone

On May 24, 2016, at 15:35, Austin Zheng via swift-evolution 
 wrote:


If you pattern match on a type that is declared internal or private, it is 
impossible for the compiler to not have an exhaustive list of subclasses that 
it can check against.


Austin


On Tue, May 24, 2016 at 1:29 PM, Leonardo Pessoa  wrote:

I like this but I think it would be a lot hard to ensure you have all
subclasses covered. Think of frameworks that could provide many
unsealed classes. You could also have an object that would have to
handle a large subtree (NSObject?) and the order in which the cases
are evaluated would matter just as in exception handling in languages
such as Java (or require some evaluation from the compiler to raise
warnings). I'm +1 for this but these should be open-ended like strings
and require the default case.

On 24 May 2016 at 17:08, Austin Zheng via swift-evolution

 wrote:
> I have been hoping for the exhaustive pattern matching feature for a while
> now, and would love to see a proposal.
>
> Austin
>
> On Tue, May 24, 2016 at 1:01 PM, Matthew Johnson via swift-evolution
>  wrote:
>>
>> Swift currently requires a default pattern matching clause when you switch
>> on an existential or a non-final class even if the protocol or class is
>> non-public and all cases are covered.  It would be really nice if the
>> default clause were not necessary in this case.  The compiler has the
>> necessary information to prove exhaustiveness.
>>
>> Related to this is the idea of introducing something like a `sealed`
>> modifier that could be applied to public protocols and classes.  The
>> protocol or class would be visible when the module is imported, but
>> conformances or subclasses outside the declaring module would be prohibited.
>> Internal and private protocols and classes would implicitly be sealed since
>> they are not visible outside the module.  Any protocols that inherit from a
>> sealed protocol or classes that inherit from a sealed class would also be
>> implicitly sealed (if we didn’t do this the sealing of the superprotocol /
>> superclass could be violated by conforming to or inheriting from a
>> subprotocol / subclass).
>>
>> Here are examples that I would like to see be valid:
>>
>> protocol P {}
>> // alternatively public sealed protocol P {}
>> struct P1: P {}
>> struct P2: P {}
>>
>> func p(p: P) -> Int {
>> switch p {
>> case is P1: return 1 // alternatively an `as` cast
>> case is P2: return 2 // alternatively an `as` cast
>> }
>> }
>>
>> class C {}
>> // alternatively public sealed class C 

Re: [swift-evolution] [Pitch] Exhaustive pattern matching forprotocols and classes

[Leonardo Pessoa via swift-evolution]

Limiting the amount of subclasses is not really a good idea as you would need 
to introduce another mechanism in the language while the proposed feature 
requires much less. And you're thinking only about the restrictive set 
(internal and private) and forgetting the more open end (public). Why is it so 
bad for this proposal to support requiring the default case? If its possible 
for the compiler to discover you covered all possible cases it would be fine 
not having default but IMHO in most cases it will find out there are more not 
explicitly covered.


-Original Message-
From: "David Sweeris" 
Sent: ‎24/‎05/‎2016 11:01 PM
To: "Austin Zheng" 
Cc: "Leonardo Pessoa" ; "swift-evolution" 

Subject: Re: [swift-evolution] [Pitch] Exhaustive pattern matching forprotocols 
and classes

Or if there was a way to declare that a class/protocol can only have a defined 
set of subclasses/conforming types.

Sent from my iPhone

On May 24, 2016, at 15:35, Austin Zheng via swift-evolution 
 wrote:


If you pattern match on a type that is declared internal or private, it is 
impossible for the compiler to not have an exhaustive list of subclasses that 
it can check against.


Austin


On Tue, May 24, 2016 at 1:29 PM, Leonardo Pessoa  wrote:

I like this but I think it would be a lot hard to ensure you have all
subclasses covered. Think of frameworks that could provide many
unsealed classes. You could also have an object that would have to
handle a large subtree (NSObject?) and the order in which the cases
are evaluated would matter just as in exception handling in languages
such as Java (or require some evaluation from the compiler to raise
warnings). I'm +1 for this but these should be open-ended like strings
and require the default case.

On 24 May 2016 at 17:08, Austin Zheng via swift-evolution

 wrote:
> I have been hoping for the exhaustive pattern matching feature for a while
> now, and would love to see a proposal.
>
> Austin
>
> On Tue, May 24, 2016 at 1:01 PM, Matthew Johnson via swift-evolution
>  wrote:
>>
>> Swift currently requires a default pattern matching clause when you switch
>> on an existential or a non-final class even if the protocol or class is
>> non-public and all cases are covered.  It would be really nice if the
>> default clause were not necessary in this case.  The compiler has the
>> necessary information to prove exhaustiveness.
>>
>> Related to this is the idea of introducing something like a `sealed`
>> modifier that could be applied to public protocols and classes.  The
>> protocol or class would be visible when the module is imported, but
>> conformances or subclasses outside the declaring module would be prohibited.
>> Internal and private protocols and classes would implicitly be sealed since
>> they are not visible outside the module.  Any protocols that inherit from a
>> sealed protocol or classes that inherit from a sealed class would also be
>> implicitly sealed (if we didn’t do this the sealing of the superprotocol /
>> superclass could be violated by conforming to or inheriting from a
>> subprotocol / subclass).
>>
>> Here are examples that I would like to see be valid:
>>
>> protocol P {}
>> // alternatively public sealed protocol P {}
>> struct P1: P {}
>> struct P2: P {}
>>
>> func p(p: P) -> Int {
>> switch p {
>> case is P1: return 1 // alternatively an `as` cast
>> case is P2: return 2 // alternatively an `as` cast
>> }
>> }
>>
>> class C {}
>> // alternatively public sealed class C {}
>> class C1: C {}
>> class C2: C {}
>>
>> func c(c: C) -> Int {
>> switch c {
>> case is C1: return 1 // alternatively an `as` cast
>> case is C2: return 2 // alternatively an `as` cast
>> case is C: return 0   // alternatively an `as` cast
>> }
>> }
>>
>> I am wondering if this is something the community is interested in.  If
>> so, I am wondering if this is something that might be possible in the Swift
>> 3 timeframe (maybe just for private and internal protocols and classes) or
>> if it should wait for Swift 4 (this is likely the case).
>>
>> -Matthew
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Namespaces

[Leonardo Pessoa via swift-evolution]

Adrian, I myself don't see a reason other than "Objective-C never had it so why 
bother about it now?" Most (if not all) .net languages support optional 
namespaces and even PHP began supporting it in version 5 (if I'm not sure if 
the version is right). No technical reason against and I'm particularly in 
favour too so let's hear the others in the group.

-Original Message-
From: "Adrian Zubarev via swift-evolution" 
Sent: ‎20/‎05/‎2016 09:16 AM
To: "swift-evolution@swift.org" 
Subject: [swift-evolution] [Discussion] Namespaces

I want to revive this topic.


Is there any technical reason why we can’t have namespaces in Swift? I’ve found 
just a few threads about namespaces, but most of them had arguments to use 
modules instead.


I’m fine with modules but they just don’t serve everything I would want to. I 
can’t enforce the developer to use the modules name if there is no naming 
conflict.


I asked in the SwiftPM mail list for a easier Xcode integration of modules, but 
the response is exactly the opposite for using modules for namespaces (read 
below).


If I’m building one huge project I don’t want to build a lot of different 
modules just shiny namespaces and clean code.


So I ask the community again why can’t we have optional namespaces?
-- 
Adrian Zubarev
Sent with Airmail


Am 19. Mai 2016 bei 22:33:19, Daniel Dunbar (daniel_dun...@apple.com) schrieb:
Right now modules are most appropriately used at the same granularity that 
frameworks or shared libraries would be used in C/Obj-C/C++. This is the 
situation for which the variety of access control modifiers in Swift and things 
like Whole Module Optimization were designed for. While there are a lot of 
reasons to like modules as a way to provide namespaces, they really haven't 
been designed to provide these very fine grained namespaces.


My guess is that the right answer here doesn't really involve the Xcode 
integration, but rather figuring out the right way that these concepts fit into 
the language in a first class way. I would expect concepts like submodules or 
namespaces to be language concepts that Xcode just exposes, not something that 
was coupled together.


 - Daniel


On May 18, 2016, at 12:37 PM, Adrian Zubarev via swift-build-dev 
 wrote:


I’d like to discuss an idea that will make development in Xcode easier. I 
assume that SwiftPM will see its Xcode integration when the final version will 
be released.
Problem I’ll try to describe is mostly about namespaces. Right now some people 
abuses enums, struct or classes to create a namespace for a specific need.


class Reference {
class String { … }
class Character {
enum Error { … }
}


private init() {}
}


This will create a pseudo namespace for the nested types:


* Reference.String
* Reference.Character
* Reference.Character.Error


One could argue of using modules instead of abusing a class here, which is a 
great argument.


The problem that comes to my mind here is that we will have to create 
subprojects inside our main project file and using the references to them just 
to achieve that shiny namespace.
One could also use SwiftPM, which is awesome, but there is a need to re-build 
the module if any changes have been done. As soon as we’ll create some complex 
dependencies between different modules this will get messy.


Before posting here I asked Joe Groff if there is any mailing list I can use to 
discuss my idea. He told me this might be a good place, because I was referring 
to the package manager. Then I’ve done my research to not create any redundant 
thread, but I only found one topic about the integration of SwiftPM in Xcode: 
https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html


So here are my thoughts about a deeper integration of SwiftPM here:


- What if Xcode will introduce two new types of groups (the folder color could 
be orange like Swift for example, or even contain the bird icon).
- These groups are analogous to already existing group types except they’ll 
represent Swift modules / packages
- Basically we’ll have a single project file with multiple modules, where these 
modules should only exist inside that project (this is my own need right now)
- Such a package / module group will have a configurable utilities, where one 
could configure the modules
- This will reduce the re-building process, allow us to keep everything (not 
only .a or we’ll be able to hide .a files and just keep the sourcefiles inside 
such groups) inside a single project, gain the shiny namespaces like above, and 
make the file management way easier 
- This also should allow us create cross-dependencies if there is a good need 
for that in our project


+ MainProject
|
+—Reference (module)
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Leonardo Pessoa via swift-evolution]

Matthew's right. The first thing here is to define a consistent rule
which takes no exceptions and then apply this rule to every existing
or new keyword and attribute.

On 18 May 2016 at 18:02, Matthew Johnson  wrote:
>
>> On May 18, 2016, at 3:55 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>>
>>> I may be wrong but I don't remember any other case of a keyword in
>>> Swift composed of two or more words, so I believe these should be
>>> exceptions.
>>
>> `typealias` and `associatedtype` are the main examples; there were huge 
>> catfights on swift-evolution about whether the latter should be 
>> `associatedtype`, `associatedType`, or `associated_type`. There are also a 
>> number of attributes like `@noescape` and `@discardableResult`, which aren't 
>> 100% consistent.
>
> Yeah, some of these changes which may feel like low hanging fruit to some 
> turn out to take a lot of energy.
>
> If we’re going to pursue more of these kinds of changes, I would prefer a 
> comprehensive proposal that evaluates everything, establishes well defined 
> conventions, and then applies the changes holistically.
>
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

[Leonardo Pessoa via swift-evolution]

> Hello Swift community,
>
> The review of "SE-0091: Improving operator requirements in protocols" begins 
> now and runs through May 23. The proposal is available here:
>
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md
>
> * What is your evaluation of the proposal?

Allow for consistent code when implementing operators. I'd go a bit
further and say any operator functions should be declared like this
but this seems to be the case for another proposal.

> * Is the problem being addressed significant enough to warrant a 
> change to Swift?

Yes.

> * Does this proposal fit well with the feel and direction of Swift?

Yes.

> * If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

Yes. In C# operator overloading is done exactly like this (but also
only like this).

> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

A quick reading.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Leonardo Pessoa via swift-evolution]

I may be wrong but I don't remember any other case of a keyword in
Swift composed of two or more words, so I believe these should be
exceptions. I would agree best to change these keywords for others
consisting of only one word but I myself have no suggestion what those
could be. Otherwise I'd rather keep them as-is.

On 18 May 2016 at 17:38, Michael Peternell via swift-evolution
 wrote:
> Hi Erica,
>
> "didset" and "willset" are outliers in the general rule that when combining 
> multiple words into an identifier, that you should use camelCase. which rule 
> is more important? I'd like to introduce a third rule: don't fix it if it 
> isn't broken, or more mildly: if in doubt, keep it the way it is. or another 
> one: embrace precedent.. "@IBOutlet" is also not all-lowercase, should it be 
> changed too? I'd say no, because in objc it is called "IBOutlet" as well. 
> Also, for my Apple Mail client, "didset" and "willset" are marked as typos, 
> but "didSet" and "willSet" is okay :)
>
> => I vote for "didSet" and "willSet".
>
> I think we should be more careful when trying to argue with "consistency". It 
> sounds objective, when in reality it's often very subjective, because 
> Immanuel Kant's imperative is ambiguous ;) there are multiple ways to be 
> consistent. If you are saying that something is inconsistent, you either 
> assert a specific rule of consistency (like "keywords are always lowercase"), 
> or you must argue that there is no general/sane rule under which the 
> individual parts of the system are consistent.
>
> And for all the others who want to abolish didSet and willSet completely:
> NO WAY! they are both useful and I even used them for real code. For example, 
> from code in my bachelors thesis (it's about polygons):
>
> public var points: Array = [] {
> didSet {
> _area = nil
> _centroid = nil
> }
> }
>
> I want to cache the _area and _centroid of a polygon, because I'm going to 
> use it many many times more often than I change points. I would have to 
> rewrite that code to something like
>
> private var _points: Array = []
> public var points {
> get {
> return _points
> }
> set {
> _area = nil
> _centroid = nil
> _points = newValue
> }
> }
>
> That's not better, and it probably breaks the COW-optimization of the 
> underlying array. (And don't tell me that my design is bad because I use 
> "didSet", I really don't think so.)
>
> -Michael
>
>> Am 18.05.2016 um 17:09 schrieb Erica Sadun via swift-evolution 
>> :
>>
>> didSet and willSet remain outliers in the general rule of conjoined 
>> lowercase keywords. Is there any support for bringing these outliers into 
>> the fold?
>>
>> -- E, going through her "ttd notes" this morning
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

[Leonardo Pessoa via swift-evolution]

> Hello Swift community,
>
> The review of "SE-0077: Improved operator declarations" begins now and runs 
> through May 23. The proposal is available here:
>
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md
>
> * What is your evaluation of the proposal?

I didn't follow much of the thread for this but from the description
of the proposal I can see how it adds clarity and understanding to
code. I really cannot tell the precedence of an operator I declared in
certain expressions because those precedence number don't make much
sense. The idea of describing the precedence of the operator compared
to other groups of operators seems to add a lot more of understanding
to my code. Just forgive me if I didn't see this but I expect that I
cannot declare an operator belonging to more than one group or compare
to more than one group for precedence (thou I see some situations
being able to asset precedence against more than one group could be
useful).

> * Is the problem being addressed significant enough to warrant a 
> change to Swift?

Yes.

> * Does this proposal fit well with the feel and direction of Swift?

Yes.

> * If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

C# allowed for operator overloading but not declaring new operators
thus all precedence was already defined by the language.

> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

A quick reading.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

[Leonardo Pessoa via swift-evolution]

> Hello Swift community,
>
> The review of "SE-0089: Renaming String.init(_: T)" begins now and runs 
> through May 23. The proposal is available here:
>
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md
>
> * What is your evaluation of the proposal?

As described in the proposal, it makes sense. I never faced the issue
myself but agree to the change. I'd also go with Jacob's version
'init(describing:)' since there is no guarantee the resulting string
will be printed but will surely describe the object used as argument.

> * Is the problem being addressed significant enough to warrant a 
> change to Swift?

As outlined by the proposal, yes.

> * Does this proposal fit well with the feel and direction of Swift?

Yes.

> * If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

None.

> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

A quick reading.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0087: Rename lazy to @lazy

[Leonardo Pessoa via swift-evolution]

> The review of "SE-0087: Rename lazy to @lazy" begins now and runs through May 
> 23. The proposal is available here:
>
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0087-lazy-attribute.md
>
> * What is your evaluation of the proposal?

I have nothing against lazy as a keyword but I also like there is a
rule/policy to keep keyword/attribute consistency so I'd give it a go.

> * Is the problem being addressed significant enough to warrant a 
> change to Swift?

Yes.

> * Does this proposal fit well with the feel and direction of Swift?

Yes.

> * If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

None.

> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

A quick reading.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Requiring special keyword to mark protocol implementation methods

[Leonardo Pessoa via swift-evolution]

Hi Vladmir!

There is something very similar to this in C#. I like this but I'd
like to enhance it a little bit. I don't think it's necessary to
decorate protocol methods any further but some warnings by the
compiler would be welcome, like when pushing a type to adopt a
protocol through an extension when the type already implements a
protocol method (we should need an annotation to tell the compiler we
understand this). This would be my version of the proposal:

protocol IX {
   func somethingA()
   func somethingB()
}

class X {
   func somethingA() { ... }
}

@warn_implemented(IX.somethingA)  // any better ideas?
extension X : IX {
   func something() implements IX.somethingB { ... }
}

My issue here is: what if I need to adopt two protocols (from
different vendors, I suppose) which require the same method and
signature but for each interface you're expected to have a different
outcome? I think better than just saying a method is an implementation
required by a protocol is to say explicitly which protocol required
that implementation. I'd also suggest a syntax for declaring a method
that is not visible but through a cast to the protocol if that makes
any sense to you.

A method implementation can have a different name if you remember two
different protocols could use the same name and signature; a new name
would disambiguate them to us, the implements part would disambiguate
for the compiler.

What do you think?

On 18 May 2016 at 04:28, Vladimir.S via swift-evolution
 wrote:
> I'd like to discuss declaration of protocol implementation in types.
>
> Ideas of this pitch is partially based on Erica Sadun's thread:
> [Pitch] Requiring proactive overrides for default protocol implementations.
> http://thread.gmane.org/gmane.comp.lang.swift.evolution/15496
> And on this draft of proposal:
> https://gist.github.com/erica/fc66e6f6335750d737e5512797e8284a
>
> I had read "Winding down the Swift 3 release" message, but feel like this
> proposal makes "improvements to the consistency and feel of the language"
> and supports the "goal of making Swift 4 as source compatible with Swift 3
> as we can reasonably accomplish". Or this can be discussed as 'after Swift
> 3.0' feature.
>
>
> The main idea of my proposal
>
> Swift should help us to be explicit about what methods were defined in type
> specifically to fulfill a protocol requirements. And so we will have more
> understandable and self-documented code that is explicit regarding the fact
> of protocol implementation(for reader of our code and for compiler).
>
> Additionally this can help to reduce potential
> problems/error/misunderstanding in case some protocol requirement(method)
> were *removed* - in this case (currently) our type will still have a method
> as implementation but no such requirement in conformed protocol yet.
>
>
> Details
>
> I propose to introduce *implement* keyword to 'mark' the methods(in type)
> that were defined in order to conform to protocol.
> Also, *reimplement* keyword is proposed to reflect the fact that method is
> declared in *both* : in the type and in protocol extension (only in
> extension, no definition of the method in protocol itself)
>
>
> Rules
>
> * Each method in type defined to fulfill the protocol conformance should be
> marked with `implement` keyword:
> implement func protocolRequirement() {..}
>
> * Compiler produces *warning* if the same function is declared in type and
> in protocol extension in case class conformed to that protocol. To 'fix' the
> warning, `reimplement` should be used.
> reimplement func f() {..} // we aware that the same method in protocol
> extension
>
> * don't need to mark methods for type if conformance to protocol defined by
> separate type extension
>
> * `reimplement` can be placed in defining type or as special declaration in
> type extension anywhere in source code:
> extension Type {
>   reimplement methodDeclaredInBothTypeAndInProtocolExtension(..); // no body
> here. probably `;` is required - to be discussed
> }
> (I don't really like this requirement, but right now don't know if we can do
> the same by using any other method )
>
>
> Current behavior of protocol extension
>
> When method is declared in protocol extension(*only. no in protocol itself*)
> and in type that is conformed to the protocol, there is a possibility for
> confusion about which method will be called. Example:
>
> protocol A { func a() }
> extension A { func b() {print("Hello from b() in extension A")} }
>
> class B : A {
> func a() {}
> func b() {print("Hello from b() in B")}
> }
>
> let instance1 = B()
> instance1.b() // Hello from b() in B
>
> let instance2 : A = B()
> instance2.b() // Hello from b() in extension A
>
> func f(t: T) { t.b() }
> f(instance1) // Hello from b() in extension A
>
> In this proposal I suggest compiler will generate a *warning* in this
> case(not error). This warning can be fixed with `reimplement` 

Re: [swift-evolution] Proposal: Finalization in protocol extensions and default implementations

[Leonardo Pessoa via swift-evolution]

Adrian, what would be the meaning of this final declaration? In my
understanding, a final means there can be no more overrides of that
method but there are no implementations in a protocol so I really
don't understand this use.

On 18 May 2016 at 16:15, Matthew Johnson via swift-evolution
 wrote:
>
> On May 18, 2016, at 12:53 PM, Adrian Zubarev via swift-evolution
>  wrote:
>
> I’d like to revive this idea I posted long time ago. There is only one thing
> I need to update here:
>
> protocol MagicType: class /* missed the class constraint */ {
>
> final var foo: Int { get }
> final func boo()
> }
>
> What benefit is there in defining a protocol requirement as final?
>
> What do you guys think? Is there any technical reason why this is not
> possible?
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 5. Dezember 2015 bei 16:26:23, Adrian Zubarev
> (adrian.zuba...@devandartist.com) schrieb:
>
> Hello there,
>
> I wonder if it is a good idea to be able to finalize in protocols and
> default implementations.
>
> Here is an example:
>
> protocol MagicType {
>
> final var foo: Int { get }
> final func boo()
> }
>
> class X: MagicType {
>
> final var foo: Int {
>
> return 42
> }
>
> final func boo() {
>
> print("magic")
> }
> }
>
> class Y: X {
>
> // can't override func boo or var foo in here
> }
>
> //===//
>
> protocol SomeType {}
>
> extension SomeType {
>
> final func foo() {
>
> print("Hello World")
> }
> }
>
> class A: SomeType {}
>
> class B: SomeType {
>
> /* this should raise an error, because the class B shouldn't */
> /* be able to override that function from SomeType */
>
> func foo() {
> // do something else
> }
> }
>
> How do you anticipate this would interact with retroactive modeling of types
> which would conform the requirements of `SomeType` but also happen to have a
> `foo` method?
>
>
>
> —
> Regards Adrian
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution