Re: [swift-evolution] [Pitch] consistent public access modifiers

[Xiaodi Wu via swift-evolution]

On Thu, Feb 9, 2017 at 9:57 AM, Matthew Johnson 
wrote:

>
> On Feb 8, 2017, at 5:48 PM, Xiaodi Wu  wrote:
>
> I agree very much with rationalizing access levels, but I'm not sure I
> like this proposal for public vs. closed. How would the compiler stop me
> from editing my own code if something is closed? The answer must be that it
> can't, so I can't see it as a co-equal to open but rather simply a
> statement of intention. Therefore I think use cases for the proposed
> behavior of closed would be better served by annotations and proper
> semantic versioning.
>
>
> The most important point IMO is that they *are* co-equal in the sense that
> they define a contract between library authors, library users and the
> compiler.
>

Certainly, `open` and your proposed `closed` both represent contracts among
library authors, users, and the compiler. But so do other features that are
not access modifiers--unless your intent is to make all the (not yet
totally finalized) resilience attributes such as `@inlineable` become
access modifiers. That both `open` and the proposed `closed` are both
contracts doesn't make them both access modifiers.

To me, the reason one _could_ justify `open` being spelled like an access
modifier (which I was not supportive of, actually, though I was fine with
`public` not allowing subclassing) is that it quacks like an access
modifier in some ways. In particular, since it offers more "access" to a
class than does `public` by allowing subclassing, one can argue that it
fits at the top of a hierarchy of access levels.

As you define it, `closed` also makes additional guarantees to the end user
than does `public` by (self-)imposing restrictions on the library author.
Thus, it does not fit into a hierarchy of access modifiers where each level
is more "accessible" than the next. Put another way, my point here is that
`closed` is not the opposite of `open` in key ways, as the names might
suggest. In fact, from the perspective of a library user, both `closed` and
`open` would allow you to do more than `public`.

As you note, there are some differences in how the `closed` contract is
> supported.  But that is far less important than the meaning of the contract
> itself.
>

Since the additional guarantees of both `open` and your proposed `closed`
impose burdens on the library _author_ and offer more flexibility to the
library _user_, I feel it is highly misleading to make them co-equal but
antonyms. They are not the "opposite" of each other and the spelling would
be misleading.

Dave's comment about tools to assist with contract-compatible API evolution
> is the right way to think about this.  Of course you *can* make breaking
> changes, but we want to make it clear when you *are* making a breaking
> change, both for source and for ABI compatibility.  This will help library
> authors, but it also helps users as well as the compiler reason about code
> when we are able to offer stronger guarantees.
>

Yes, this is totally fair.


> Most notably, the behavior of public enums *already* has the API contract
> of `closed` and we do not want to remove that capability.  This proposal
> only formalizes how that contract is specified and makes it consistent
> across all kinds of types.  It *does not* introduce the idea of a closed
> semantic contract for a type.
>
> As this change didn't seem in scope for Swift 4 phase 1, I've held off on
> discussing my own thoughts on access levels. The idea I was going to
> propose in phase 2 was to have simply open and public enums (and
> protocols). I really think that completes access levels in a rational way
> without introducing another keyword.
>
>
> The reason I posted now is because formalizing this API contract for enums
> must happen before ABI is locked down, and also because there is at least
> one protocol in the standard library (`MirrorPath`) which is documented
> with the intent that it be `closed`.
>
> I understand the reluctance to introduce another keyword.  It isn’t clear
> to me what semantics you assign to `open` and `public` enums.
>
> Are you suggesting that they match the semantics defined in my proposal
> and suggesting closed enums (i.e. matching the current behavior of `public`
> enums) would require an `@closed` annotation as suggested in the Library
> Evolution document?
>

Yes, I am.


> I am opposed to this approach because it penalizes the API contract that I
> think is often the most appropriate for enums.  I strongly prefer that we
> adopt the same neutral stance that we when we introduced `open`.
>

I would not characterize `open` as a neutral stance. But that's neither
here nor there.

The problem (as I see it) with your argument is that, in general, the
following two thoughts are incompatible: (a) the additional burden of a
public API contract should be opt-in; vs. (b) there should be neutrality as
to whether or not one assumes the burden of a particular public API
contract.

Opting in means that one has made the deliberate effort of

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

[Bouke Haarsma via swift-evolution]

A big +1 for Discourse from me as well. I don't want to sign up to the 
mailing list and have mailbox overflow. I did have rules put in place 
to move the messages in a separate folder, but still the amount wasn't 
manageable. Furthermore reading the threads in Mail.app is a major pain 
as a result of different quotation styles used by various authors.


Currently I use gmane.org's nntp servers and the outdated Unison.app. 
However that app also doesn't support the various quotation styles, 
which doesn't help with following topics. I'd be very happy to use 
Discourse, as it allows me to opt-in to any discussion I'd like and 
start/stop e-mail notifications as I see fit. Also Github Issues would 
allow me to do that, but I can see the benefits Discourse would 
provide; e.g. better moderation, pinning topics for recurring topics 
and ownership of the forum's data (threads).


-Bouke


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

Re: [swift-evolution] Strings in Swift 4

[Shawn Erickson via swift-evolution]

On Thu, Feb 9, 2017 at 5:09 PM Ted F.A. van Gaalen 
wrote:

> On 10 Feb 2017, at 00:11, Dave Abrahams  wrote:
>
>
> on Thu Feb 09 2017, "Ted F.A. van Gaalen" 
> wrote:
>
> Hello Shawn
> Just google with any programming language name and “string manipulation”
> and you have enough reading for a week or so :o)
> TedvG
>
>
> That truly doesn't answer the question.  It's not, “why do people index
> strings with integers when that's the only tool they are given for
> decomposing strings?”  It's, “what do you have to do with strings that's
> hard in Swift *because* you can't index them with integers?”
>
>
> Hi Dave,
> Ok. here are just a few examples:
> Parsing and validating an ISBN code? or a (freight) container ID? or EAN13
> perhaps?
> of many of the typical combined article codes and product IDs that many
> factories and shops use?
>
> or:
>
> E.g. processing legacy files from IBM mainframes:
> extract fields from ancient data records read from very old sequential
> files,
> say, a product data record like this from a file from 1978 you’d have to
> unpack and process:
> 123534-09EVXD4568,991234,89ABCYELLOW12AGRAINESYTEMZ3453
> into:
> 123, 534, -09, EVXD45, 68,99, 1234,99, ABC, YELLOW, 12A, GRAIN, ESYSTEM,
> Z3453.
> product category, pcs, discount code, product code, price Yen, price $,
> class code, etc…
> in Cobol and PL/1 records are nearly always defined with a fixed field
> layout like this.:
> (storage was limited and very, very expensive, e.g. XML would be regarded
> as a
> "scandalous waste" even the commas in CSV files! )
>
> 01  MAILING-RECORD.
>
>05  COMPANY-NAMEPIC X(30).
>05  CONTACTS.
>10  PRESIDENT.
>15  LAST-NAME   PIC X(15).
>15  FIRST-NAME  PIC X(8).
>10  VP-MARKETING.
>15  LAST-NAME   PIC X(15).
>15  FIRST-NAME  PIC X(8).
>10  ALTERNATE-CONTACT.
>15  TITLE   PIC X(10).
>15  LAST-NAME   PIC X(15).
>15  FIRST-NAME  PIC X(8).
>05  ADDRESS PIC X(15).
>05  CITYPIC X(15).
>05  STATE   PIC XX.
>05  ZIP PIC 9(5).
>
> These are all character data fields here, except for the numeric ZIP field , 
> however in Cobol it can be treated like character data.
> So here I am, having to get the data of these old Cobol production files
> into a brand new Swift based accounting system of 2017, what can I do?
>
> How do I unpack these records and being the data into a Swift structure or 
> class?
> (In Cobol I don’t have to because of the predefined fixed format record 
> layout).
>
> AFAIK there are no similar record structures with fixed fields like this 
> available Swift?
>
> So, the only way I can think of right now is to do it like this:
>
> // mailingRecord is a Swift structure
> struct MailingRecord
> {
> var  companyName: String = “no Name”
>  var contacts: CompanyContacts
>  .
>  etc..
> }
>
> // recordStr was read here with ASCII encoding
>
> // unpack data in to structure’s properties, in this case all are Strings
> mailingRecord.companyName   = recordStr[ 0..<30]
> mailingRecord.contacts.president.lastName  = recordStr[30..<45]
> mailingRecord.contacts.president.firstName = recordStr[45..<53]
>
>
> // and so on..
>
> Ever worked for e.g. a bank with thousands of these files unchanged formats 
> for years?
>
> Any alternative, convenient en simpler methods in Swift present?
>
> These looks like examples of fix data format that could be parsed from a
byte buffer into strings, etc. Likely little need to force them via a
higher order string concept, at least not until unpacked from its compact
byte form.

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

Re: [swift-evolution] Strings in Swift 4

[Shawn Erickson via swift-evolution]

On Thu, Feb 9, 2017 at 3:45 PM Hooman Mehr  wrote:

> On Feb 9, 2017, at 3:11 PM, Dave Abrahams  wrote:
>
>
> on Thu Feb 09 2017, "Ted F.A. van Gaalen" 
> wrote:
>
> Hello Shawn
> Just google with any programming language name and “string manipulation”
> and you have enough reading for a week or so :o)
> TedvG
>
>
> That truly doesn't answer the question.  It's not, “why do people index
> strings with integers when that's the only tool they are given for
> decomposing strings?”  It's, “what do you have to do with strings that's
> hard in Swift *because* you can't index them with integers?”
>
>
> I have done some string processing. I have not encountered any algorithm
> where an integer index is absolutely needed, but sometimes it might be the
> most convenient.
>
> For example, there are valid reasons to keep side tables that hold indexes
> into a string. (such as maintaining attributes that apply to a substring or
> things like pre-computed positions of soft line breaks). It does not
> require the index to be *integer*, but maintaining validity of those
> indexes after the string is mutated requires being able to offset them back
> or forth from some position on. These operations could be less verbose and
> easier if the index happens to be integer or (efficiently) supports + -
> operators. Also, I know there are other methods to deal with such things
> and mutating a large string generally is a bad idea, but sometimes it is
> the easiest and most convenient solution to the problem at hand.
>

 The end goal of this string is for human consumption right? So such
manipulation would need need to unicode aware in the modern world? ..or is
it for some other reason?

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

Re: [swift-evolution] Warning when omitting default case for imported enums

[Slava Pestov via swift-evolution]

> On Feb 8, 2017, at 1:34 AM, Tino Heth via swift-evolution 
>  wrote:
> 
> 
>> Allowing the omission of a default case in an exhaustive switch makes the 
>> addition of a new case to the enum a breaking change. 
> Depending on the context, even with a default the change might be breaking — 
> but without giving notice to the framework client!
> Additionally, it would feel very strange for me to have a default clause for 
> bool-like enums* or other examples where there can't be any additional cases.
> 
> When there are two types of enums, the proposal makes sense for the 
> "open"-ones; but I'm not sure if I like the concept of having two kinds of 
> enum.

Why not? Bool-like enums would be declared ‘closed’, and would not require a 
default case (but adding a new case would then break ABI).

For better or worse we need the ability to define enums that admit new cases 
without breaking ABI. Whether or not this is the default for all enums, or 
enabled with a special attribute can be designed later when we send out 
evolution proposals for resilience-related features.

Slava

> 
> - Tino
> 
> * tiny anecdote: I actually have seen the equivalent of this
> 
> func reallyExhaustive(input: Bool) {
>   if input == true {
>   print("true")
>   } else if input != true {
>   print ("not true")
>   } else {
>   print("just to be save")
>   }
> }
> 
> in the wild… but I don't remember the comment I wrote ;-)
> ___
> 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] array splatting for variadic parameters

[Slava Pestov via swift-evolution]

Hi Dimitri,

I think this is a desirable feature, but nobody has got around to designing and 
implementing it yet.

Another case where it comes up is initializer inheritance. Suppose I have:

class Base {
  init(x: Int…) {}
}

class Derived : Base {
}

Currently, Derived does not inherit Base.init(), because we have no way to 
synthesize the AST which performs this ‘forwarding’.

In fact, if somebody wanted to attempt an implementation of this, handling this 
case first would be easier because then you can implement the AST node for 
splatting a vararg and get it working without worrying about parser changes 
(probably you can shoehorn it into TupleShuffleExpr). Then after a design for 
the syntax has been accepted, add the parser support on top.

Slava

> On Feb 9, 2017, at 3:51 PM, Dimitri Racordon via swift-evolution 
>  wrote:
> 
> Hello everyone.
> 
> I understand that topic has already been discussed in the past, but I failed 
> to get any information on its current state of affairs.
> 
> I guess the subject of this mail is explicit, but to make sure I’m clear, 
> here's a small snippet that illustrates the problem:
> 
> func f(args: Int…) {
>   // Some implementation ...
> }
> // Now it's impossible to call f without explicitly naming its parameters.
> 
> For many use-cases, this problem can be solved by overloading f so that it 
> explicitly accepts an array.
> 
> func f(_ args: [Int]) {
>   // Some implementation ...
> }
> 
> func f(_ args: Int…) {
>   f(args)
> }
> 
> Some people also advocate (myself generally included) that one should prefer 
> the signature explicitly marking args as an array, as the syntactic overhead 
> of wrapping the arguments with “[]” when calling f is arguably bearable. 
> However, in some other situations, this approach might not be applicable. For 
> instance, one may simply not be able to modify the original function. Another 
> use-case may be a function that should forward its own variadic parameters.
> 
> In a variety of other languages, there exists a way to do this. For instance, 
> Python can “unpack” (or splat) a list into function arguments by prefixing it 
> with *:
> 
> def f(*args):
>   # Some implementation …
> 
> f(*[1, 2, 3]) # == f(1, 2, 3)
> 
> I was wondering if such feature could be supported by Swift, and if not, why.
> 
> Syntactically, I like the use of “…”, which would mirror function signatures:
> 
> f(…[1, 2, 3]) // == f(1, 2, 3)
> 
> Thanks.
> 
> --
> Dimitri Racordon
> 
> ___
> 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-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Ted Kremenek via swift-evolution]

> On Feb 9, 2017, at 4:09 PM, Matthew Johnson  wrote:
> 
> 
>> On Feb 9, 2017, at 6:04 PM, Ted Kremenek > > wrote:
>> 
>> 
>>> On Feb 9, 2017, at 3:52 PM, Ted Kremenek via swift-users 
>>> mailto:swift-us...@swift.org>> wrote:
>>> 
 I’ve been mostly silent in this conversation largely because I didn’t 
 realize it was leading up to a formal decision.  I wish it would have 
 followed the proposal process so it was clear to everyone that a decision 
 was being considered and this was our chance to offer input.  
>>> 
>>> FWIW, I am not ignoring this thread.  At some point there was diminishing 
>>> signal on the thread, and it felt like the category of opinions that had 
>>> been voiced had been vocalized on the thread.  Looping in swift-users into 
>>> that thread would have been a good thing to do in hindsight so more people 
>>> felt like they had a chance to participate.  Based on what I am seeing in 
>>> reaction to this decision, however, I’m not seeing much new signal.
>> 
>> Just to add to this point — new insights on this topic are welcome, and will 
>> be paid attention to.  The decision to change to a forum is because that was 
>> evaluated as being the best thing for the community, based on the range of 
>> opinions provided and the tradeoffs made.  If there is something important 
>> that was missed, obviously that is not going to be ignored.  We want to do 
>> the right thing.  So far I still feel that moving to a forum software is the 
>> right choice, but I’d like to do that in a way that allows people to still 
>> participate effectively via email.
> 
> Is there any way to have a trial run so we can evaluate the email experience 
> of using the forum software before we make the final switch?  I agree that 
> this sounds like the right direction, but it’s hard to know what the email 
> experience will really be like until we give it a try for a week or so.

I need to formalize a plan, but yes I’d like to trial this somehow.  Nate Cook 
created a staged installation of Discourse when the thread on swift-evolution 
was happening and there was some useful telemetry out of that experiment (such 
as how rich text email interacted with doing inline replies).  Moving to 
Discourse (or some alternate forum software if we decide Discourse is not a 
fit) would be a staged thing.  The main question to me is how do we do a 
meaningful trial without actually doing the real discussions in the forum 
(while the mailing lists are still running).___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Feb 9, 2017, at 6:04 PM, Ted Kremenek  wrote:
> 
> 
>> On Feb 9, 2017, at 3:52 PM, Ted Kremenek via swift-users 
>> mailto:swift-us...@swift.org>> wrote:
>> 
>>> I’ve been mostly silent in this conversation largely because I didn’t 
>>> realize it was leading up to a formal decision.  I wish it would have 
>>> followed the proposal process so it was clear to everyone that a decision 
>>> was being considered and this was our chance to offer input.  
>> 
>> FWIW, I am not ignoring this thread.  At some point there was diminishing 
>> signal on the thread, and it felt like the category of opinions that had 
>> been voiced had been vocalized on the thread.  Looping in swift-users into 
>> that thread would have been a good thing to do in hindsight so more people 
>> felt like they had a chance to participate.  Based on what I am seeing in 
>> reaction to this decision, however, I’m not seeing much new signal.
> 
> Just to add to this point — new insights on this topic are welcome, and will 
> be paid attention to.  The decision to change to a forum is because that was 
> evaluated as being the best thing for the community, based on the range of 
> opinions provided and the tradeoffs made.  If there is something important 
> that was missed, obviously that is not going to be ignored.  We want to do 
> the right thing.  So far I still feel that moving to a forum software is the 
> right choice, but I’d like to do that in a way that allows people to still 
> participate effectively via email.

Is there any way to have a trial run so we can evaluate the email experience of 
using the forum software before we make the final switch?  I agree that this 
sounds like the right direction, but it’s hard to know what the email 
experience will really be like until we give it a try for a week or so.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ted Kremenek via swift-evolution]

> On Feb 9, 2017, at 3:52 PM, Ted Kremenek via swift-users 
>  wrote:
> 
>> I’ve been mostly silent in this conversation largely because I didn’t 
>> realize it was leading up to a formal decision.  I wish it would have 
>> followed the proposal process so it was clear to everyone that a decision 
>> was being considered and this was our chance to offer input.  
> 
> FWIW, I am not ignoring this thread.  At some point there was diminishing 
> signal on the thread, and it felt like the category of opinions that had been 
> voiced had been vocalized on the thread.  Looping in swift-users into that 
> thread would have been a good thing to do in hindsight so more people felt 
> like they had a chance to participate.  Based on what I am seeing in reaction 
> to this decision, however, I’m not seeing much new signal.

Just to add to this point — new insights on this topic are welcome, and will be 
paid attention to.  The decision to change to a forum is because that was 
evaluated as being the best thing for the community, based on the range of 
opinions provided and the tradeoffs made.  If there is something important that 
was missed, obviously that is not going to be ignored.  We want to do the right 
thing.  So far I still feel that moving to a forum software is the right 
choice, but I’d like to do that in a way that allows people to still 
participate effectively via email.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ted Kremenek via swift-evolution]

> On Feb 9, 2017, at 9:30 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Feb 9, 2017, at 11:16 AM, Jens Alfke via swift-users 
>> mailto:swift-us...@swift.org>> wrote:
>> 
>> 
>>> On Feb 9, 2017, at 3:41 AM, Jan Neumüller via swift-users 
>>> mailto:swift-us...@swift.org>> wrote:
>>> 
>>> I would prefer http://www.fudforum.org/  that has 
>>> good mailing list support, too.
>> 
>> Well, we appear to have completely opposite opinions on UI/usability. I took 
>> a look at fudforum and yeah, to my eyes it exemplifies the awful clutter 
>> that’s been a hallmark of web forums since before PHPBB. There’s so much 
>> visual noise it’s very hard to parse or to find anything. Clearly designed 
>> by a coder with a big hammer named “”. I’m not a UI designer, but 
>> I’ve worked extensively with UI designers (I spent 15 years at Apple working 
>> on stuff like iChat and AppleScript) so I think I have some grounding in the 
>> field.
>> 
>> I do believe, though, that whatever solution swift.org  
>> switches to needs to have good email support. That way the people who hate 
>> the web UI, or who just don’t prefer to use the web for discussions, can 
>> keep using email as we do today. This is perfectly feasible to do; again, 
>> groups.io  is a good example. 
>> 
>> Here my concern is that I have not found a way to configure Discourse to 
>> make its email notifications work well as a substitute for a mailing list. I 
>> have admin privileges on a Discourse installation run by my employer, so 
>> I’ve looked through the entire admin UI for ways to improve the emails, and 
>> some of the problems don’t seem fixable by tweaking settings.
>> 
>> At this point I’m going to shut up because it sounds like the decision has 
>> been made, and I don’t want to contribute to further bike-shedding.
> 
> I’ve been mostly silent in this conversation largely because I didn’t realize 
> it was leading up to a formal decision.  I wish it would have followed the 
> proposal process so it was clear to everyone that a decision was being 
> considered and this was our chance to offer input.  

FWIW, I am not ignoring this thread.  At some point there was diminishing 
signal on the thread, and it felt like the category of opinions that had been 
voiced had been vocalized on the thread.  Looping in swift-users into that 
thread would have been a good thing to do in hindsight so more people felt like 
they had a chance to participate.  Based on what I am seeing in reaction to 
this decision, however, I’m not seeing much new signal.

> 
> I really like the experience of participating in the community via email.  If 
> I knew a decision was being seriously considered I would have taken a closer 
> look at Discourse and likely offered more input.  I will be disappointed if 
> the experience of participating is not at least as good as it is using email.

This opinion was also eloquently voiced on the swift-evolution thread, and FWIW 
it is one that holds weight.  I really want to strike a good balance here so we 
do what is best for the overall community.  The reality is that we are pivoting 
from one technology to another, and with a web forum naturally the prime 
experience is in that forum.  Email will likely feel “second class” to some 
degree simply because it, by design, is not the primary interaction model for 
forum software like Discourse.  That doesn’t mean the email experience has to 
be terrible.  Ideally it is good experience so that people who want to continue 
to use email for participation can continue to do so.

> 
> One of the most important reasons I like using email is that Mail offers a 
> great experience on iPhone and iPad.  I am skeptical that a web-based forum 
> could offer the same level of convenience and efficiency for keeping up with 
> the community that email provides.

Email unfortunately provides an uneven experience across clients, including the 
support for threading, what kind of content authorship affordances provided, 
and so forth.  I totally get what you are saying though, being someone who uses 
Mail in the same way.


> 
> I hope that we do find a way to configure our tool (probably Discourse) so 
> that the email experience on iPhone and iPad does not suffer.  If we can meet 
> that criteria and *also* offer the advantages of a web-based tool I will be 
> very happy.  But I think the current email experience on iPhone and iPad 
> should set a minimum criteria that any tool must meet.

This is something I’m interested in achieving as well.  There are a lot of 
tradeoffs here, and I suspect what we end up with will be tradeoffs that will 
be highly subjective from person to person.  The “does not suffer” is hard to 
qualify, at least objectively, because it likely will be *different* from what 
we have now.

> 
>> 
>> —Jens
>> ___
>> swift-users mailing list
>> swift-us...@swift.o

[swift-evolution] array splatting for variadic parameters

[Dimitri Racordon via swift-evolution]

Hello everyone.

I understand that topic has already been discussed in the past, but I failed to 
get any information on its current state of affairs.

I guess the subject of this mail is explicit, but to make sure I’m clear, 
here's a small snippet that illustrates the problem:

func f(args: Int…) {
  // Some implementation ...
}
// Now it's impossible to call f without explicitly naming its parameters.

For many use-cases, this problem can be solved by overloading f so that it 
explicitly accepts an array.

func f(_ args: [Int]) {
  // Some implementation ...
}

func f(_ args: Int…) {
  f(args)
}

Some people also advocate (myself generally included) that one should prefer 
the signature explicitly marking args as an array, as the syntactic overhead of 
wrapping the arguments with “[]” when calling f is arguably bearable. However, 
in some other situations, this approach might not be applicable. For instance, 
one may simply not be able to modify the original function. Another use-case 
may be a function that should forward its own variadic parameters.

In a variety of other languages, there exists a way to do this. For instance, 
Python can “unpack” (or splat) a list into function arguments by prefixing it 
with *:

def f(*args):
  # Some implementation …

f(*[1, 2, 3]) # == f(1, 2, 3)

I was wondering if such feature could be supported by Swift, and if not, why.

Syntactically, I like the use of “…”, which would mirror function signatures:

f(…[1, 2, 3]) // == f(1, 2, 3)

Thanks.

--
Dimitri Racordon

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

Re: [swift-evolution] Strings in Swift 4

[Hooman Mehr via swift-evolution]

> On Feb 9, 2017, at 3:11 PM, Dave Abrahams  wrote:
> 
> 
> on Thu Feb 09 2017, "Ted F.A. van Gaalen"  wrote:
> 
>> Hello Shawn
>> Just google with any programming language name and “string manipulation”
>> and you have enough reading for a week or so :o)
>> TedvG
> 
> That truly doesn't answer the question.  It's not, “why do people index
> strings with integers when that's the only tool they are given for
> decomposing strings?”  It's, “what do you have to do with strings that's
> hard in Swift *because* you can't index them with integers?”

I have done some string processing. I have not encountered any algorithm where 
an integer index is absolutely needed, but sometimes it might be the most 
convenient. 

For example, there are valid reasons to keep side tables that hold indexes into 
a string. (such as maintaining attributes that apply to a substring or things 
like pre-computed positions of soft line breaks). It does not require the index 
to be integer, but maintaining validity of those indexes after the string is 
mutated requires being able to offset them back or forth from some position on. 
These operations could be less verbose and easier if the index happens to be 
integer or (efficiently) supports + - operators. Also, I know there are other 
methods to deal with such things and mutating a large string generally is a bad 
idea, but sometimes it is the easiest and most convenient solution to the 
problem at hand.


> 
>>> On 9 Feb 2017, at 16:48, Shawn Erickson  wrote:
>>> 
>>> I also wonder what folks are actually doing that require indexing
>>> into strings. I would love to see some real world examples of what
>>> and why indexing into a string is needed. Who is the end consumer of
>>> that string, etc.
>>> 
>>> Do folks have so examples?
>>> 
>>> -Shawn
>>> 
>>> On Thu, Feb 9, 2017 at 6:56 AM Ted F.A. van Gaalen via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> Hello Hooman
>>> That invalidates my assumptions, thanks for evaluating
>>> it's more complex than I thought.
>>> Kind Regards
>>> Ted
>>> 
 On 8 Feb 2017, at 00:07, Hooman Mehr >>> > wrote:
 
 
> On Feb 7, 2017, at 12:19 PM, Ted F.A. van Gaalen via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> I now assume that:
>  1. -= a “plain” Unicode character (codepoint?)  can result in one 
> glyph.=-
 
 What do you mean by “plain”? Characters in some Unicode scripts are
 by no means “plain”. They can affect (and be affected by) the
 characters around them, they can cause glyphs around them to
 rearrange or combine (like ligatures) or their visual
 representation (glyph) may float in the same space as an adjacent
 glyph (and seem to be part of the “host” glyph), etc. So, the
 general relationship of a character and its corresponding glyph (if
 there is one) is complex and depends on context and surroundings
 characters.
 
>  2. -= a  grapheme cluster always results in just a single glyph, 
> true? =- 
 
 False
 
>  3. The only thing that I can see on screen or print are glyphs 
> (“carvings”,visual elements that stand on their own )
 
 The visible effect might not be a visual shape. It may be for example, the 
 way the surrounding shapes change or re-arrange.
 
> 4.  In this context, a glyph is a humanly recognisable visual form of 
> a character,
 
 Not in a straightforward one to one fashion, not even in Latin / Roman 
 script.
 
> 5. On this level (the glyph, what I can see as a user) it is not 
> relevant and also not detectable
> with how many Unicode scalars (codepoints ?), grapheme, or even 
> on what kind
> of encoding the glyph was based upon.
 
 False
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
> 
> -- 
> -Dave

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

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

[Joshua Alvarado via swift-evolution]

The decision to move from the mailing list may have surprised many but the
discussion on it has been ongoing very strong. Sorry you feel like you
didn't get to voice your opinion which I believe everyone should have the
opportunity to. I think many agree that email has it's perks on iPhone and
iPad but many have advocated for Disclosure because a way to improve  the
Swift community's communication. It is very hard to please every person in
the community with each change but as a community we should support each
other in the discussions and decisions that are put forth (agreeing or
not). I believe we can find a way to get the experience with Disclosure.
Get it best for iPhone and iPad users, as well as email support and those
who want to just use Disclosure only. This may not all happen at once but
it will come as we progress.

On Thu, Feb 9, 2017 at 10:30 AM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Feb 9, 2017, at 11:16 AM, Jens Alfke via swift-users <
> swift-us...@swift.org> wrote:
>
>
> On Feb 9, 2017, at 3:41 AM, Jan Neumüller via swift-users <
> swift-us...@swift.org> wrote:
>
> I would prefer http://www.fudforum.org/ that has good mailing list
> support, too.
>
>
> Well, we appear to have completely opposite opinions on UI/usability. I
> took a look at fudforum and yeah, to my eyes it exemplifies the awful
> clutter that’s been a hallmark of web forums since before PHPBB. There’s so
> much visual noise it’s very hard to parse or to find anything. Clearly
> designed by a coder with a big hammer named “”. I’m not a UI
> designer, but I’ve worked extensively with UI designers (I spent 15 years
> at Apple working on stuff like iChat and AppleScript) so I think I have
> some grounding in the field.
>
> I do believe, though, that *whatever solution swift.org
>  switches to needs to have good email support*. That
> way the people who hate the web UI, or who just don’t prefer to use the web
> for discussions, can keep using email as we do today. This is perfectly
> feasible to do; again, groups.io is a good example.
>
> Here my concern is that *I have not found a way to configure Discourse to
> make its email notifications work well as a substitute for a mailing list.*
> I have admin privileges on a Discourse installation run by my employer, so
> I’ve looked through the entire admin UI for ways to improve the emails, and
> some of the problems don’t seem fixable by tweaking settings.
>
> At this point I’m going to shut up because it sounds like the decision has
> been made, and I don’t want to contribute to further bike-shedding.
>
>
> I’ve been mostly silent in this conversation largely because I didn’t
> realize it was leading up to a formal decision.  I wish it would have
> followed the proposal process so it was clear to everyone that a decision
> was being considered and this was our chance to offer input.
>
> I really like the experience of participating in the community via email.
> If I knew a decision was being seriously considered I would have taken a
> closer look at Discourse and likely offered more input.  I will be
> disappointed if the experience of participating is not at least as good as
> it is using email.
>
> One of the most important reasons I like using email is that Mail offers a
> great experience on iPhone and iPad.  I am skeptical that a web-based forum
> could offer the same level of convenience and efficiency for keeping up
> with the community that email provides.
>
> I hope that we do find a way to configure our tool (probably Discourse) so
> that the email experience on iPhone and iPad does not suffer.  If we can
> meet that criteria and *also* offer the advantages of a web-based tool I
> will be very happy.  But I think the current email experience on iPhone and
> iPad should set a minimum criteria that any tool must meet.
>
>
> —Jens
> ___
> swift-users mailing list
> swift-us...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Joshua Alvarado
alvaradojosh...@gmail.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Strings in Swift 4

[Dave Abrahams via swift-evolution]

on Thu Feb 09 2017, "Ted F.A. van Gaalen"  wrote:

> Hello Shawn
> Just google with any programming language name and “string manipulation”
> and you have enough reading for a week or so :o)
> TedvG

That truly doesn't answer the question.  It's not, “why do people index
strings with integers when that's the only tool they are given for
decomposing strings?”  It's, “what do you have to do with strings that's
hard in Swift *because* you can't index them with integers?”

>> On 9 Feb 2017, at 16:48, Shawn Erickson  wrote:
>> 
>> I also wonder what folks are actually doing that require indexing
>> into strings. I would love to see some real world examples of what
>> and why indexing into a string is needed. Who is the end consumer of
>> that string, etc.
>> 
>> Do folks have so examples?
>> 
>> -Shawn
>> 
>> On Thu, Feb 9, 2017 at 6:56 AM Ted F.A. van Gaalen via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> Hello Hooman
>> That invalidates my assumptions, thanks for evaluating
>> it's more complex than I thought.
>> Kind Regards
>> Ted
>> 
>>> On 8 Feb 2017, at 00:07, Hooman Mehr >> > wrote:
>>> 
>>> 
 On Feb 7, 2017, at 12:19 PM, Ted F.A. van Gaalen via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 I now assume that:
   1. -= a “plain” Unicode character (codepoint?)  can result in one 
 glyph.=-
>>> 
>>> What do you mean by “plain”? Characters in some Unicode scripts are
>>> by no means “plain”. They can affect (and be affected by) the
>>> characters around them, they can cause glyphs around them to
>>> rearrange or combine (like ligatures) or their visual
>>> representation (glyph) may float in the same space as an adjacent
>>> glyph (and seem to be part of the “host” glyph), etc. So, the
>>> general relationship of a character and its corresponding glyph (if
>>> there is one) is complex and depends on context and surroundings
>>> characters.
>>> 
   2. -= a  grapheme cluster always results in just a single glyph, 
 true? =- 
>>> 
>>> False
>>> 
   3. The only thing that I can see on screen or print are glyphs 
 (“carvings”,visual elements that stand on their own )
>>> 
>>> The visible effect might not be a visual shape. It may be for example, the 
>>> way the surrounding shapes change or re-arrange.
>>> 
  4.  In this context, a glyph is a humanly recognisable visual form of 
 a character,
>>> 
>>> Not in a straightforward one to one fashion, not even in Latin / Roman 
>>> script.
>>> 
  5. On this level (the glyph, what I can see as a user) it is not 
 relevant and also not detectable
  with how many Unicode scalars (codepoints ?), grapheme, or even 
 on what kind
  of encoding the glyph was based upon.
>>> 
>>> False
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
>

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

Re: [swift-evolution] Nil-rejection operator

[Rob Mayoff via swift-evolution]

On Thu, Feb 9, 2017 at 2:25 PM, Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

> I wonder if an alternative to the original proposal might be to allow
> throw on the right hand side? So you could do:
>
> let y = x ?? throw myError
>
>
You can do this today:

extension Error {
func throwMe() throws -> R { throw self }
}

let y = try x ?? MyError().throwMe()
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

[Matthew Johnson via swift-evolution]

> On Feb 9, 2017, at 2:44 PM, David Hart  wrote:
> 
> 
> On 9 Feb 2017, at 20:43, Matthew Johnson via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>> 
>> Sent from my iPad
>> 
>> On Feb 9, 2017, at 1:30 PM, Hooman Mehr via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> 
 On Feb 9, 2017, at 10:47 AM, Joe Groff via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
> On Feb 9, 2017, at 4:26 AM, Step Christopher via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Looks good. Minor comments below:
> The typealias 'T5' is repeated as both an initial composition, and as a 
> demonstration of combining typealiases. 
> 
>> This proposal merges the concepts of class and AnyObject, which now have 
>> the same meaning: they represent an existential for classes. They are 
>> four solutions to this dilemna:
>> Do nothing.
>> Replace all uses of AnyObject by class, breaking source compatibility.
>> Replace all uses of class by AnyObject, breaking source compatibility.
>> Redefine AnyObject as typealias AnyObject = class.
> I agree with other comments on recommending 4 here, and covering the 
> others as alternatives
>>  
>> I
>>  agree that we need the typealias for compatibility. I think it's still 
>> worth discussing whether the `AnyObject` typealias should *only* be 
>> there for compatibility; it could be deprecated or obsoleted in Swift 4 
>> or future language versions.
>>> 
>>> I think it might be worth keeping to provide a more sensible capitalization 
>>> alternative than lower case “class” when used as a type name:
>>> 
>>> var obj: class // this looks weird because of capitalization.
>>> 
>>> var obj: AnyObject // this looks better.
>> 
>> I agree that it looks better and would choose AnyObject if source 
>> compatibility weren't an issue.  One option that wasn't listed was to drop 
>> 'class' but use a multi-release deprecation strategy and a fix-it to 
>> facilitate a smooth transition.  If the community is willing to adopt this 
>> approach it would be my first choice.
> 
> You mean option 3?

Pretty much, but option 3 does not make it clear that it won’t break source 
immediately in Swift 4.  I think it becomes much more reasonable if Swift 3.1 
code still compiles in Swift 4 mode, but with a deprecation warning.

The reason I prefer `AnyObject` to `class` is because I think it’s ugly to have 
`class` as the name of an existential type.  Type names are uppercase in Swift. 
 It is also used to compose with protocols which also use uppercase names in 
Swift.  Because it appears in contexts which use an uppercase convention it 
makes sense for this to have an uppercase name.  `AnyObject` seems like the 
obvious choice if we’re going to go in that direction.

> 
>>> 
 
 -Joe
 ___
 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] Class and Subclass Existentials (Round 2)

[David Hart via swift-evolution]

> On 9 Feb 2017, at 20:43, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Feb 9, 2017, at 1:30 PM, Hooman Mehr via swift-evolution 
>>  wrote:
>> 
>> 
 On Feb 9, 2017, at 10:47 AM, Joe Groff via swift-evolution 
  wrote:
 On Feb 9, 2017, at 4:26 AM, Step Christopher via swift-evolution 
  wrote:
 Looks good. Minor comments below:
 The typealias 'T5' is repeated as both an initial composition, and as a 
 demonstration of combining typealiases. 
 
> This proposal merges the concepts of class and AnyObject, which now have 
> the same meaning: they represent an existential for classes. They are 
> four solutions to this dilemna:
> Do nothing.
> Replace all uses of AnyObject by class, breaking source compatibility.
> Replace all uses of class by AnyObject, breaking source compatibility.
> Redefine AnyObject as typealias AnyObject = class.
 I agree with other comments on recommending 4 here, and covering the 
 others as alternatives
>>> I agree that we need the typealias for compatibility. I think it's still 
>>> worth discussing whether the `AnyObject` typealias should *only* be there 
>>> for compatibility; it could be deprecated or obsoleted in Swift 4 or future 
>>> language versions.
>> 
>> I think it might be worth keeping to provide a more sensible capitalization 
>> alternative than lower case “class” when used as a type name:
>> 
>> var obj: class // this looks weird because of capitalization.
>> 
>> var obj: AnyObject // this looks better.
> 
> I agree that it looks better and would choose AnyObject if source 
> compatibility weren't an issue.  One option that wasn't listed was to drop 
> 'class' but use a multi-release deprecation strategy and a fix-it to 
> facilitate a smooth transition.  If the community is willing to adopt this 
> approach it would be my first choice.

You mean option 3?

>> 
>>> 
>>> -Joe
>>> ___
>>> 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] Nil-rejection operator

[Haravikk via swift-evolution]

> On 9 Feb 2017, at 19:08, Hooman Mehr via swift-evolution 
>  wrote:
> 
> I think the best solution is overloading the existing ?? operator. It is very 
> easy to do:
> 
> func ??(lhs: T?, rhs: U) throws -> T {
> 
> if let lhs = lhs { return lhs } else { throw rhs }
> }
> 
> then you can say:
> 
> do {
> 
> let y = try x ?? myError
> 
> } catch ...
> 
> It might even make sense to add to the standard library.

Interesting idea, but what if you actually want that error assigned to y?

I wonder if an alternative to the original proposal might be to allow throw on 
the right hand side? So you could do:

let y = x ?? throw myError

That'd be a lot more explicit about what's going on than a new operator would 
be. It might require defining throw as being some kind of special type though 
that can be used to satisfy only function signatures that call for it 
explicitly like:

func ??(lhs:T?, rhs:U) throws -> T {
guard let lhs = lhs else { throw rhs.error }
return lhs
}

Same idea really, but the difference being that this wouldn't be a type that 
satisfies generics, but can be used for any operator that could allow a throw 
to occur within its operands.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Nil-rejection operator

[Hooman Mehr via swift-evolution]

Two more tiny overloads is all takes to fix it:

func ??(lhs: T?, rhs: T) -> T {

if let lhs = lhs { return lhs } else { return rhs }
}

func ??(lhs: T?, rhs: U) -> Error {

if let lhs = lhs { return lhs } else { return rhs }
}


> On Feb 9, 2017, at 12:01 PM, Jack Newcombe  wrote:
> 
> While this is nice, it adds ambiguity to the nil-coalescing operator. For 
> example, when using nil-coalescing with a wrapped error value and an 
> unwrapped error value as operands:
> 
> let optionalError: Errors? = nil
> let result = optionalError ?? Errors.generic
> 
> The above will result in an "Ambiguous use of operator" error. Even if you 
> were to somehow constrain the first argument to arguments of non-error types, 
> it would still make the operator incongruous.
> 
> On Thu, Feb 9, 2017 at 7:08 PM, Hooman Mehr  > wrote:
> I think the best solution is overloading the existing ?? operator. It is very 
> easy to do:
> 
> func ??(lhs: T?, rhs: U) throws -> T {
> 
> if let lhs = lhs { return lhs } else { throw rhs }
> }
> 
> then you can say:
> 
> do {
> 
> let y = try x ?? myError
> 
> } catch ...
> 
> It might even make sense to add to the standard library.
> 
>> On Feb 9, 2017, at 12:04 AM, Jack Newcombe via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> This can actually be accomplished now using a closure:
>> 
>>  let value = optionalValue ?? { throw CustomError.failure }()
>> 
>> However, this adds a layer of indirection that I’m not keen on and lacks the 
>> readability and maintainability of a well-defined operator.
>> 
>> The problem with changing the nil-coalescing operator is that it means 
>> allowing the second operand to be a statement rather than an expression, 
>> which I assume would be seen as an unacceptable.
>> 
>>> On 9 Feb 2017, at 07:56, Brent Royal-Gordon >> > wrote:
>>> 
 On Feb 8, 2017, at 12:00 PM, Jack Newcombe via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 I propose the introduction of a nil-rejection operator (represented here 
 as !!) as a complement to the above operators.
 .
 This operator should allow an equivalent behaviour to the forced 
 unwrapping of a variable, but with the provision of an error to throw in 
 place of throwing a fatal error.
 
 - value !! Error :
if value is nil, throw non-fatal error
if value is not nil, return value
 
 Example of how this syntax might work (Where CustomError: Error):
 
let value = try optionalValue !! CustomError.failure
>>> 
>>> Rather than invent a new operator, I'd prefer to make `throw` an expression 
>>> rather than a statement. Then you could write:
>>> 
>>> let value = optionalValue ?? throw CustomError.Failure
>>> 
>>> One issue here would be figuring out the proper return type for `throw`. 
>>> Although if `Never` were a subtype-of-all-types, that would of course work. 
>>> :^)
>>> 
>>> -- 
>>> 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] Nil-rejection operator

[Jack Newcombe via swift-evolution]

While this is nice, it adds ambiguity to the nil-coalescing operator. For
example, when using nil-coalescing with a wrapped error value and an
unwrapped error value as operands:

let optionalError: Errors? = nil
let result = optionalError ?? Errors.generic

The above will result in an "Ambiguous use of operator" error. Even if you
were to somehow constrain the first argument to arguments of non-error
types, it would still make the operator incongruous.

On Thu, Feb 9, 2017 at 7:08 PM, Hooman Mehr  wrote:

> I think the best solution is overloading the existing ?? operator. It is
> very easy to do:
>
> func ??(lhs: T?, rhs: U) throws -> T {
>
>
> if let lhs = lhs { return lhs } else { throw rhs }
> }
>
> then you can say:
>
> do {
>
>
> let y = try x ?? myError
>
>
> } catch ...
>
> It might even make sense to add to the standard library.
>
> On Feb 9, 2017, at 12:04 AM, Jack Newcombe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This can actually be accomplished now using a closure:
>
> let value = optionalValue ?? { throw CustomError.failure }()
>
> However, this adds a layer of indirection that I’m not keen on and lacks
> the readability and maintainability of a well-defined operator.
>
> The problem with changing the nil-coalescing operator is that it means
> allowing the second operand to be a statement rather than an expression,
> which I assume would be seen as an unacceptable.
>
> On 9 Feb 2017, at 07:56, Brent Royal-Gordon 
> wrote:
>
> On Feb 8, 2017, at 12:00 PM, Jack Newcombe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I propose the introduction of a nil-rejection operator (represented here
> as !!) as a complement to the above operators.
> .
> This operator should allow an equivalent behaviour to the forced
> unwrapping of a variable, but with the provision of an error to throw in
> place of throwing a fatal error.
>
> - value !! Error :
> if value is nil, throw non-fatal error
> if value is not nil, return value
>
> Example of how this syntax might work (Where CustomError: Error):
>
> let value = try optionalValue !! CustomError.failure
>
>
> Rather than invent a new operator, I'd prefer to make `throw` an
> expression rather than a statement. Then you could write:
>
> let value = optionalValue ?? throw CustomError.Failure
>
> One issue here would be figuring out the proper return type for `throw`.
> Although if `Never` were a subtype-of-all-types, that would of course work.
> :^)
>
> --
> 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] Class and Subclass Existentials (Round 2)

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Feb 9, 2017, at 1:30 PM, Hooman Mehr via swift-evolution 
>  wrote:
> 
> 
>>> On Feb 9, 2017, at 10:47 AM, Joe Groff via swift-evolution 
>>>  wrote:
>>> On Feb 9, 2017, at 4:26 AM, Step Christopher via swift-evolution 
>>>  wrote:
>>> Looks good. Minor comments below:
>>> The typealias 'T5' is repeated as both an initial composition, and as a 
>>> demonstration of combining typealiases. 
>>> 
 This proposal merges the concepts of class and AnyObject, which now have 
 the same meaning: they represent an existential for classes. They are four 
 solutions to this dilemna:
 Do nothing.
 Replace all uses of AnyObject by class, breaking source compatibility.
 Replace all uses of class by AnyObject, breaking source compatibility.
 Redefine AnyObject as typealias AnyObject = class.
>>> I agree with other comments on recommending 4 here, and covering the others 
>>> as alternatives
>> I agree that we need the typealias for compatibility. I think it's still 
>> worth discussing whether the `AnyObject` typealias should *only* be there 
>> for compatibility; it could be deprecated or obsoleted in Swift 4 or future 
>> language versions.
> 
> I think it might be worth keeping to provide a more sensible capitalization 
> alternative than lower case “class” when used as a type name:
> 
> var obj: class // this looks weird because of capitalization.
> 
> var obj: AnyObject // this looks better.

I agree that it looks better and would choose AnyObject if source compatibility 
weren't an issue.  One option that wasn't listed was to drop 'class' but use a 
multi-release deprecation strategy and a fix-it to facilitate a smooth 
transition.  If the community is willing to adopt this approach it would be my 
first choice.

> 
>> 
>> -Joe
>> ___
>> 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] Class and Subclass Existentials (Round 2)

[Hooman Mehr via swift-evolution]

> On Feb 9, 2017, at 10:47 AM, Joe Groff via swift-evolution 
>  wrote:
>> On Feb 9, 2017, at 4:26 AM, Step Christopher via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> Looks good. Minor comments below:
>> The typealias 'T5' is repeated as both an initial composition, and as a 
>> demonstration of combining typealiases. 
>> 
>>> This proposal merges the concepts of class and AnyObject, which now have 
>>> the same meaning: they represent an existential for classes. They are four 
>>> solutions to this dilemna:
>>> Do nothing.
>>> Replace all uses of AnyObject by class, breaking source compatibility.
>>> Replace all uses of class by AnyObject, breaking source compatibility.
>>> Redefine AnyObject as typealias AnyObject = class.
>> I agree with other comments on recommending 4 here, and covering the others 
>> as alternatives
>>>  
>>> I
>>>  agree that we need the typealias for compatibility. I think it's still 
>>> worth discussing whether the `AnyObject` typealias should *only* be there 
>>> for compatibility; it could be deprecated or obsoleted in Swift 4 or future 
>>> language versions.

I think it might be worth keeping to provide a more sensible capitalization 
alternative than lower case “class” when used as a type name:

var obj: class // this looks weird because of capitalization.

var obj: AnyObject // this looks better.

> 
> -Joe
> ___
> 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-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Milos Jakovljevic via swift-evolution]

+1 for Discourse

Sent from my iPhone

> On Feb 9, 2017, at 14:32, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I’m sorry for you, but I don’t think we’re talking in this thread about being 
> old and wearing glasses or not. My eyes aren’t the best either, but I’m not 
> complaining about that or try to make this as an argument against 
> minimalistic designs. (Coloring is a different story of its own.)
> 
> How’s that needed UI at all? It’s an ugly piece of web art compared to these 
> days standards.
> 
> What’s the problem with endless scrolling? We’re all doing that every day on 
> the internet, scrolling down to find and click on the next or # button for 
> the purpose to again being able to scroll down to click on the same button 
> over and over again. Discourse took that unnecessary click from you and 
> provides a nice side scroller to quickly jump to a specific reply you want.
> 
> Reading all your complains lets me think that it’s exactly how you would 
> think about sites like stackoverflow for example (or even the minimalistic 
> swift.org).
> 
> I’m not trying to be offensive by any means. I just criticized your choice 
> from my esthetic point of view.
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 9. Februar 2017 um 14:07:05, Jan Neumüller via swift-users 
> (swift-us...@swift.org) schrieb:
> 
>> I see NEEDED UI.
> 
> ___
> 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] Nil-rejection operator

[Hooman Mehr via swift-evolution]

I think the best solution is overloading the existing ?? operator. It is very 
easy to do:

func ??(lhs: T?, rhs: U) throws -> T {

if let lhs = lhs { return lhs } else { throw rhs }
}

then you can say:

do {

let y = try x ?? myError

} catch ...

It might even make sense to add to the standard library.

> On Feb 9, 2017, at 12:04 AM, Jack Newcombe via swift-evolution 
>  wrote:
> 
> This can actually be accomplished now using a closure:
> 
>   let value = optionalValue ?? { throw CustomError.failure }()
> 
> However, this adds a layer of indirection that I’m not keen on and lacks the 
> readability and maintainability of a well-defined operator.
> 
> The problem with changing the nil-coalescing operator is that it means 
> allowing the second operand to be a statement rather than an expression, 
> which I assume would be seen as an unacceptable.
> 
>> On 9 Feb 2017, at 07:56, Brent Royal-Gordon  wrote:
>> 
>>> On Feb 8, 2017, at 12:00 PM, Jack Newcombe via swift-evolution 
>>>  wrote:
>>> 
>>> I propose the introduction of a nil-rejection operator (represented here as 
>>> !!) as a complement to the above operators.
>>> .
>>> This operator should allow an equivalent behaviour to the forced unwrapping 
>>> of a variable, but with the provision of an error to throw in place of 
>>> throwing a fatal error.
>>> 
>>> - value !! Error :
>>> if value is nil, throw non-fatal error
>>> if value is not nil, return value
>>> 
>>> Example of how this syntax might work (Where CustomError: Error):
>>> 
>>> let value = try optionalValue !! CustomError.failure
>> 
>> Rather than invent a new operator, I'd prefer to make `throw` an expression 
>> rather than a statement. Then you could write:
>> 
>>  let value = optionalValue ?? throw CustomError.Failure
>> 
>> One issue here would be figuring out the proper return type for `throw`. 
>> Although if `Never` were a subtype-of-all-types, that would of course work. 
>> :^)
>> 
>> -- 
>> 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] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

[André Videla via swift-evolution]

Lots of emotions here. 
There is something I would like to point out that I don't feel is clear enough. 

The goal of this move is to move the community forward. The way it is moving 
the community forward is by increasing the scope of people able to participate 
while allowing new capabilities for the organizers (E.g. : more powerful 
moderation tools). 

As a community we need to accept putting aside our mild annoyances in order to 
allow the community to grow in a healthy way. 

Let us celebrate  the thousand the people who will benefit from moving to a web 
based forum. 
Whether they contribute, browse or simply share it to their friends they will 
enjoy a more open and accessible platform.

Andre Videla 

> On 9 Feb 2017, at 19:30, Michael Sheaver via swift-evolution 
>  wrote:
> 
> I have a simple question along this line: How does expanding the capabilities 
> of Swift detract or impair its use in a fully OO manner? From what I have 
> seen, if you want to use it in a strictly OO manner, great! If you want to 
> use it in a strictly functional manner, no problem. If you want to use it in 
> hybrid mode, go for it.
> 
> Giving developers the flexibility to code in the manner they are most 
> comfortable with can only improve creativity and productivity. It also 
> improves the appeal of the language to others.
> 
> Unless, of course, I am missing something here.
> 
>> On Feb 9, 2017, 1:09 PM -0500, Jan Neumüller via swift-users 
>> , wrote:
>> This is just for explanation. I have given up for the content, the world 
>> does move in this direction and I can’t stop it.
>> 
>>> On 9 Feb 2017, at 18:29, Cihat Gündüz  wrote:
>>> 
>>> @Jan: Your arguments are very subjective if not even insulting and 
>>> derogatory to many people who invest a lot of time and effort in crafting 
>>> those things you despise so openly. Here are just a few example quotes for 
>>> you to reflect your language:
>>> 
>>> "I despise fp“, „is so annoying“, "made Swift imo a worse language“, "I 
>>> hate ‚modern' or as I call it ugly“, "Today’s standards are a bag of pain“, 
>>> "crappy sites als Facebook, Twitter, Instagram, Stackoverflow, add lots of 
>>> other 'cool' sites“, "I can’t stand scrolling“, "I hate both“, "todays 
>>> absolutely useless crap“, …
>> 
>> FP: I think many coders hate it with a passion, a fact fans of fp don’t 
>> generally like. For me it’s the total brain breaking “logic” behind FP and 
>> lambda calculus. I started programming with assembly on mos6502 and  took 
>> most languages since then. There is one family I never got my brain wrapped 
>> around it as it works against the complete working of my brain: functional 
>> programming.
>> 
>> And yes I think the push for more fp elements made Swift a worse language. 
>> How is that an attack?
>> 
>> How should I call stuff that induces eye strain and headaches from usage? 
>> Todays modern web technics most often lead to imo totally bad websites that 
>> are a clearly worse then most sites before the web 2.0 hype. Sorry if I am 
>> to direct as a german but dancing around topics is a waste of time.
>> 
>> 
>>> Please be aware that this behavior is against the Code of Conduct of the 
>>> Swift Community. Let’s try to stay objective and justify different opinions 
>>> rationally instead of personally. Of course it is valid for you to say that 
>>> you don’t like FP or that you don’t like how the world is changing in 
>>> general. But please be aware that you have to add the reason why you think 
>>> it is so in detail, so we understand your thinking and can overcome changes 
>>> to the wrong direction. Senctences like „I despise FP“ without any 
>>> explanation are not a form of constructive feedback though, nobody will 
>>> learn anything from that kind of thing. Currently you’re merely expressing 
>>> your anger here, no more, no less.
>> 
>> Anger? And there is no reason after gotten steamrolled by evolution on this 
>> discussion by simply NOT ASKING US (Swift-Users) and simply presented a 
>> decision? Should we be happy that a part of the community sees itself 
>> apparently as more important then the rest? Of course I’m angry after such 
>> actions - who wouldn’t?
>> 
>> 
>>> @Jens: One of the biggest reasons I’m all for Discourse is the fact that 
>>> it’s open source. What this implies is: You know exactly what happens with 
>>> the data you save there, and, there is no dependency on a third-party 
>>> service which could change or even close over time. This is why I’m against 
>>> groups.io, GitHub Issues or any other non-open source solution. What it 
>>> also means is: If the open source tool we decided to go for (Discourse) 
>>> doesn’t have good support for emails yet, we can implement it ourselves, 
>>> improve the existing support or add a bridge to another open source tool 
>>> that can deal with that.
>> 
>> Sadly Discourse stands under a license that makes contributing a nogo for 
>> many. As a BSD dev I NEVER would put any of my code u

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

[Joe Groff via swift-evolution]

> On Feb 9, 2017, at 4:26 AM, Step Christopher via swift-evolution 
>  wrote:
> 
> Looks good. Minor comments below:
> 
>> let t: P & C // Compiler error: subclass contraint must be in first position
> 
> Typo: contraint should be constraint
>>  
>> 
>> ...
>> typealias TA4 = D & P2
>> typealias TA5 = E & P2
>> 
>> typealias TA5 = TA1 & TA2
>> typealias TA5 = class & P1 & class & P2 // Expansion
>> typealias TA5 = class & P1 & P2 // Normalization
>> // TA5 is valid
> 
> The typealias 'T5' is repeated as both an initial composition, and as a 
> demonstration of combining typealiases. 
> 
> 
>> This proposal merges the concepts of class and AnyObject, which now have the 
>> same meaning: they represent an existential for classes. They are four 
>> solutions to this dilemna:
>> Do nothing.
>> Replace all uses of AnyObject by class, breaking source compatibility.
>> Replace all uses of class by AnyObject, breaking source compatibility.
>> Redefine AnyObject as typealias AnyObject = class.
> 
> I agree with other comments on recommending 4 here, and covering the others 
> as alternatives
>>  
>> I
>>  agree that we need the typealias for compatibility. I think it's still 
>> worth discussing whether the `AnyObject` typealias should *only* be there 
>> for compatibility; it could be deprecated or obsoleted in Swift 4 or future 
>> language versions.

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

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

[David Sweeris via swift-evolution]

> On Feb 9, 2017, at 09:30, Matthew Johnson via swift-users 
>  wrote:
> 
> 
>>> On Feb 9, 2017, at 11:16 AM, Jens Alfke via swift-users 
>>>  wrote:
>>> 
>>> 
>>> On Feb 9, 2017, at 3:41 AM, Jan Neumüller via swift-users 
>>>  wrote:
>>> 
>>> I would prefer http://www.fudforum.org/ that has good mailing list support, 
>>> too.
>> 
>> Well, we appear to have completely opposite opinions on UI/usability. I took 
>> a look at fudforum and yeah, to my eyes it exemplifies the awful clutter 
>> that’s been a hallmark of web forums since before PHPBB. There’s so much 
>> visual noise it’s very hard to parse or to find anything. Clearly designed 
>> by a coder with a big hammer named “”. I’m not a UI designer, but 
>> I’ve worked extensively with UI designers (I spent 15 years at Apple working 
>> on stuff like iChat and AppleScript) so I think I have some grounding in the 
>> field.
>> 
>> I do believe, though, that whatever solution swift.org switches to needs to 
>> have good email support. That way the people who hate the web UI, or who 
>> just don’t prefer to use the web for discussions, can keep using email as we 
>> do today. This is perfectly feasible to do; again, groups.io is a good 
>> example. 
>> 
>> Here my concern is that I have not found a way to configure Discourse to 
>> make its email notifications work well as a substitute for a mailing list. I 
>> have admin privileges on a Discourse installation run by my employer, so 
>> I’ve looked through the entire admin UI for ways to improve the emails, and 
>> some of the problems don’t seem fixable by tweaking settings.
>> 
>> At this point I’m going to shut up because it sounds like the decision has 
>> been made, and I don’t want to contribute to further bike-shedding.
> 
> I’ve been mostly silent in this conversation largely because I didn’t realize 
> it was leading up to a formal decision.  I wish it would have followed the 
> proposal process so it was clear to everyone that a decision was being 
> considered and this was our chance to offer input.  
> 
> I really like the experience of participating in the community via email.  If 
> I knew a decision was being seriously considered I would have taken a closer 
> look at Discourse and likely offered more input.  I will be disappointed if 
> the experience of participating is not at least as good as it is using email.

I'm pretty sure that Discourse's mailing list support is why so many people 
suggested it.

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

Re: [swift-evolution] I think we need more to our type calculus

[Joe Groff via swift-evolution]

> On Feb 8, 2017, at 12:09 PM, Daryle Walker via swift-evolution 
>  wrote:
> 
> I’ve been trying to get the maximum of a list of counts. I started by using 
> “myCollection.map { $0.myCountProperty }.reduce(0, max)”. Then I thought I 
> should really use the value closest to negative infinity as the base. The 
> problem is how to get that value. The current hard-coded “0” works because 
> the count type ultimately aliases “Int”, but shouldn’t have to count on that. 
> I put in “MyCountType.min”, where “MyCountType” is hard coded from the docs 
> of “myCountProperty”, but I shouldn’t have to do that either.
> 
> There is a “type(of:)” global function, which I did use. But not only did I 
> have to make up an expression to go in there, its return value, some sort of 
> meta-type stuff I don’t understand, can’t be used on the right side of a 
> “typealias” construct. I ultimately used “let lowestCount = type(of: 
> anElement.myCountProperty).min” to get what I needed.

type(of:) does evaluate its argument, since for things like classes you need to 
know the value you're asking of a type for. However, you can avoid hardcoding a 
type at all in this case by using contextual lookup:

myCollection.map { $0.myCountProperty }.reduce(.min, max)

`.foo` will look up static members inside the contextual type of the expression.

-Joe

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

Re: [swift-evolution] protocol-oriented integers (take 2)

[Max Moiseev via swift-evolution]

Hi Ben,

The reason to include init?(exactly:T) as a requirement for 
the Arithmetic (now Number) protocol was that it already refines 
ExpressibleByIntegerLiteral, so it would be quite weird to *not* allow explicit 
initialization.

Generic conversion to floating point types is not covered by this proposal, but 
is somewhat related:
https://github.com/apple/swift/blob/master/stdlib/public/core/FloatingPoint.swift.gyb#L257
 

https://github.com/apple/swift/blob/master/stdlib/public/core/FloatingPoint.swift.gyb#L1588
 

There are a few unimplemented (but planned) initializers on FloatingPoint and 
BinaryFloatingPoint that would make this happen.
If and when those are implemented, you would be able to write the version of 
numericCast() using those.

Hope this answers your question.

Max

> On Jan 17, 2017, at 9:43 AM, Ben Rimmington  wrote:
> 
> 
> 
>   public protocol Arithmetic {
> init?(exactly source: T)
>   }
> 
>   public protocol BinaryInteger : Arithmetic {
> init?(exactly source: T)
>   }
> 
> Should the `init?(exactly:)` initializers belong to the same protocol?
> Would this allow generic conversions between integer and floating-point types?
> For example, a failable `numericCast` function.
> 
> -- Ben
> 

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

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

[Michael Sheaver via swift-evolution]

I have a simple question along this line: How does expanding the capabilities 
of Swift detract or impair its use in a fully OO manner? From what I have seen, 
if you want to use it in a strictly OO manner, great! If you want to use it in 
a strictly functional manner, no problem. If you want to use it in hybrid mode, 
go for it.

Giving developers the flexibility to code in the manner they are most 
comfortable with can only improve creativity and productivity. It also improves 
the appeal of the language to others.

Unless, of course, I am missing something here.

On Feb 9, 2017, 1:09 PM -0500, Jan Neumüller via swift-users 
, wrote:
> This is just for explanation. I have given up for the content, the world does 
> move in this direction and I can’t stop it.
>
> > On 9 Feb 2017, at 18:29, Cihat Gündüz  wrote:
> >
> > @Jan: Your arguments are very subjective if not even insulting and 
> > derogatory to many people who invest a lot of time and effort in crafting 
> > those things you despise so openly. Here are just a few example quotes for 
> > you to reflect your language:
> >
> > "I despise fp“, „is so annoying“, "made Swift imo a worse language“, "I 
> > hate ‚modern' or as I call it ugly“, "Today’s standards are a bag of pain“, 
> > "crappy sites als Facebook, Twitter, Instagram, Stackoverflow, add lots of 
> > other 'cool' sites“, "I can’t stand scrolling“, "I hate both“, "todays 
> > absolutely useless crap“, …
>
> FP: I think many coders hate it with a passion, a fact fans of fp don’t 
> generally like. For me it’s the total brain breaking “logic” behind FP and 
> lambda calculus. I started programming with assembly on mos6502 and  took 
> most languages since then. There is one family I never got my brain wrapped 
> around it as it works against the complete working of my brain: functional 
> programming.
>
> And yes I think the push for more fp elements made Swift a worse language. 
> How is that an attack?
>
> How should I call stuff that induces eye strain and headaches from usage? 
> Todays modern web technics most often lead to imo totally bad websites that 
> are a clearly worse then most sites before the web 2.0 hype. Sorry if I am to 
> direct as a german but dancing around topics is a waste of time.
>
>
> > Please be aware that this behavior is against the Code of Conduct of the 
> > Swift Community. Let’s try to stay objective and justify different opinions 
> > rationally instead of personally. Of course it is valid for you to say that 
> > you don’t like FP or that you don’t like how the world is changing in 
> > general. But please be aware that you have to add the reason why you think 
> > it is so in detail, so we understand your thinking and can overcome changes 
> > to the wrong direction. Senctences like „I despise FP“ without any 
> > explanation are not a form of constructive feedback though, nobody will 
> > learn anything from that kind of thing. Currently you’re merely expressing 
> > your anger here, no more, no less.
>
> Anger? And there is no reason after gotten steamrolled by evolution on this 
> discussion by simply NOT ASKING US (Swift-Users) and simply presented a 
> decision? Should we be happy that a part of the community sees itself 
> apparently as more important then the rest? Of course I’m angry after such 
> actions - who wouldn’t?
>
>
> > @Jens: One of the biggest reasons I’m all for Discourse is the fact that 
> > it’s open source. What this implies is: You know exactly what happens with 
> > the data you save there, and, there is no dependency on a third-party 
> > service which could change or even close over time. This is why I’m against 
> > groups.io, GitHub Issues or any other non-open source solution. What it 
> > also means is: If the open source tool we decided to go for (Discourse) 
> > doesn’t have good support for emails yet, we can implement it ourselves, 
> > improve the existing support or add a bridge to another open source tool 
> > that can deal with that.
>
> Sadly Discourse stands under a license that makes contributing a nogo for 
> many. As a BSD dev I NEVER would put any of my code under GPL. This is a 
> thing we should not forget - fitting licenses.
>
> Jan___
> swift-users mailing list
> swift-us...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Is it possible to compile swift code to dynamic library ?

[Derrick Ho via swift-evolution]

If you use the "swiftc" command it will create an executable. Maybe there
is a command in there to create linker files which you can offer to your c
project.

Any one on this threat super knowledgeable on the "swiftc" command?
On Thu, Feb 9, 2017 at 1:53 AM Zheng Ping via swift-evolution <
swift-evolution@swift.org> wrote:

>
> Compile swift code to dynamic library(a *.so file which is compatible with
> C), and let the *.so file can be linked directly by a pure C project.
>
> --
> with kind regards
> ___
> 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-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Rien via swift-evolution]

> On 09 Feb 2017, at 18:29, Cihat Gündüz via swift-evolution 
>  wrote:
> 
> @Jan: Your arguments are very subjective if not even insulting and derogatory 
> to many people who invest a lot of time and effort in crafting those things 
> you despise so openly. Here are just a few example quotes for you to reflect 
> your language:
> 
> "I despise fp“, „is so annoying“, "made Swift imo a worse language“, "I hate 
> ‚modern' or as I call it ugly“, "Today’s standards are a bag of pain“, 
> "crappy sites als Facebook, Twitter, Instagram, Stackoverflow, add lots of 
> other 'cool' sites“, "I can’t stand scrolling“, "I hate both“, "todays 
> absolutely useless crap“, …
> 
> Please be aware that this behavior is against the Code of Conduct of the 
> Swift Community. Let’s try to stay objective and justify different opinions 
> rationally instead of personally. Of course it is valid for you to say that 
> you don’t like FP or that you don’t like how the world is changing in 
> general. But please be aware that you have to add the reason why you think it 
> is so in detail, so we understand your thinking and can overcome changes to 
> the wrong direction. Senctences like „I despise FP“ without any explanation 
> are not a form of constructive feedback though, nobody will learn anything 
> from that kind of thing. Currently you’re merely expressing your anger here, 
> no more, no less.

I don’t think he did. He expressed his opinions rather forcefully, but we all 
tick different. He did not call anybody out specifically.
And just because somebody spend a lot of time on something does not make it 
great. And maybe they need to hear it this way to “get the message”. Sugar 
coating can do a lot of harm.

Btw: this does remind me of some of things I heard about a former -too early 
deceased- leader of apple...

Rien.


> 
> 
> @Jens: One of the biggest reasons I’m all for Discourse is the fact that it’s 
> open source. What this implies is: You know exactly what happens with the 
> data you save there, and, there is no dependency on a third-party service 
> which could change or even close over time. This is why I’m against 
> groups.io, GitHub Issues or any other non-open source solution. What it also 
> means is: If the open source tool we decided to go for (Discourse) doesn’t 
> have good support for emails yet, we can implement it ourselves, improve the 
> existing support or add a bridge to another open source tool that can deal 
> with that.
> 
> -- 
> Cihat Gündüz
> 
> Am 9. Februar 2017 um 15:59:33, Jan Neumüller via swift-evolution 
> (swift-evolution@swift.org) schrieb:
> 
>> Well, if the community likes it so much. Have fun with it. I will leave as I 
>> have left the Developer Forums at Apple because they became unusable.
>> 
>> 
>>> On 9 Feb 2017, at 15:17, Adrian Zubarev  
>>> wrote:
>>> 
>>> The quote below made my day dear Swift friend as I might remind you that if 
>>> modern is associated with hate in your mind, then the modern programming 
>>> language called Swift would probably be a bad choice. 
>>> 
>>> 
>> I starting to think that myself. I was very active at the beginning of Swift 
>> (way before the open sourcing) but I absolutely don’t like the increasing 
>> influence of functional programming on it. I despise fp and don’t want it in 
>> Swift. If people want it that much use Haskell 8(
>>> I might remind everyone that Discourse is open sourced and therefore tweaks 
>>> are possible. If you prefer a consistent font like on swift.org, than spell 
>>> it out and help to create a corner on the web where every Swiftier feels 
>>> right at home. 
>>> 
>>> 
>> I don’t think that Discourse is salvageable but go on. But I don’t know how 
>> one could rip out this big piece of JavaScript and keep ist functional.
>>> Personally I’d prefer (if possible) that we’d remove profile pictures from 
>>> the forum and simply have only full names (colored?) + some kind of 
>>> annotation (e.g. Core Team, etc.). Profile pictures are only gimmicks that 
>>> does not contribute to anything at all.
>>> 
>>> As Jan already said, the font (and font-size?) of the forum could match the 
>>> font from swift.org if possible. I wouldn’t mind and it’d make it a little 
>>> bit more alike.
>>> 
>>> 
>> You don’t have to care for me - Swift 4 will be the deciding step if I throw 
>> any Swift work away and return to Objective-C. The heavy functional 
>> programming push since open sourcing is so annoying and made Swift imo a 
>> worse language.
>> 
>> Jan
>> ___
>> 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/list

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

[Matthew Johnson via swift-evolution]

> On Feb 9, 2017, at 11:16 AM, Jens Alfke via swift-users 
>  wrote:
> 
> 
>> On Feb 9, 2017, at 3:41 AM, Jan Neumüller via swift-users 
>> mailto:swift-us...@swift.org>> wrote:
>> 
>> I would prefer http://www.fudforum.org/  that has 
>> good mailing list support, too.
> 
> Well, we appear to have completely opposite opinions on UI/usability. I took 
> a look at fudforum and yeah, to my eyes it exemplifies the awful clutter 
> that’s been a hallmark of web forums since before PHPBB. There’s so much 
> visual noise it’s very hard to parse or to find anything. Clearly designed by 
> a coder with a big hammer named “”. I’m not a UI designer, but I’ve 
> worked extensively with UI designers (I spent 15 years at Apple working on 
> stuff like iChat and AppleScript) so I think I have some grounding in the 
> field.
> 
> I do believe, though, that whatever solution swift.org  
> switches to needs to have good email support. That way the people who hate 
> the web UI, or who just don’t prefer to use the web for discussions, can keep 
> using email as we do today. This is perfectly feasible to do; again, 
> groups.io  is a good example. 
> 
> Here my concern is that I have not found a way to configure Discourse to make 
> its email notifications work well as a substitute for a mailing list. I have 
> admin privileges on a Discourse installation run by my employer, so I’ve 
> looked through the entire admin UI for ways to improve the emails, and some 
> of the problems don’t seem fixable by tweaking settings.
> 
> At this point I’m going to shut up because it sounds like the decision has 
> been made, and I don’t want to contribute to further bike-shedding.

I’ve been mostly silent in this conversation largely because I didn’t realize 
it was leading up to a formal decision.  I wish it would have followed the 
proposal process so it was clear to everyone that a decision was being 
considered and this was our chance to offer input.  

I really like the experience of participating in the community via email.  If I 
knew a decision was being seriously considered I would have taken a closer look 
at Discourse and likely offered more input.  I will be disappointed if the 
experience of participating is not at least as good as it is using email.

One of the most important reasons I like using email is that Mail offers a 
great experience on iPhone and iPad.  I am skeptical that a web-based forum 
could offer the same level of convenience and efficiency for keeping up with 
the community that email provides.

I hope that we do find a way to configure our tool (probably Discourse) so that 
the email experience on iPhone and iPad does not suffer.  If we can meet that 
criteria and *also* offer the advantages of a web-based tool I will be very 
happy.  But I think the current email experience on iPhone and iPad should set 
a minimum criteria that any tool must meet.

> 
> —Jens
> ___
> swift-users mailing list
> swift-us...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

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

[Cihat Gündüz via swift-evolution]

@Jan: Your arguments are very subjective if not even insulting and derogatory 
to many people who invest a lot of time and effort in crafting those things you 
despise so openly. Here are just a few example quotes for you to reflect your 
language:

"I despise fp“, „is so annoying“, "made Swift imo a worse language“, "I hate 
‚modern' or as I call it ugly“, "Today’s standards are a bag of pain“, "crappy 
sites als Facebook, Twitter, Instagram, Stackoverflow, add lots of other 'cool' 
sites“, "I can’t stand scrolling“, "I hate both“, "todays absolutely useless 
crap“, …

Please be aware that this behavior is against the Code of Conduct of the Swift 
Community. Let’s try to stay objective and justify different opinions 
rationally instead of personally. Of course it is valid for you to say that you 
don’t like FP or that you don’t like how the world is changing in general. But 
please be aware that you have to add the reason why you think it is so in 
detail, so we understand your thinking and can overcome changes to the wrong 
direction. Senctences like „I despise FP“ without any explanation are not a 
form of constructive feedback though, nobody will learn anything from that kind 
of thing. Currently you’re merely expressing your anger here, no more, no less.


@Jens: One of the biggest reasons I’m all for Discourse is the fact that it’s 
open source. What this implies is: You know exactly what happens with the data 
you save there, and, there is no dependency on a third-party service which 
could change or even close over time. This is why I’m against groups.io, GitHub 
Issues or any other non-open source solution. What it also means is: If the 
open source tool we decided to go for (Discourse) doesn’t have good support for 
emails yet, we can implement it ourselves, improve the existing support or add 
a bridge to another open source tool that can deal with that.

-- 
Cihat Gündüz

Am 9. Februar 2017 um 15:59:33, Jan Neumüller via swift-evolution 
(swift-evolution@swift.org) schrieb:

Well, if the community likes it so much. Have fun with it. I will leave as I 
have left the Developer Forums at Apple because they became unusable.


On 9 Feb 2017, at 15:17, Adrian Zubarev  wrote:

The quote below made my day dear Swift friend as I might remind you that if 
modern is associated with hate in your mind, then the modern programming 
language called Swift would probably be a bad choice. 


I starting to think that myself. I was very active at the beginning of Swift 
(way before the open sourcing) but I absolutely don’t like the increasing 
influence of functional programming on it. I despise fp and don’t want it in 
Swift. If people want it that much use Haskell 8(
I might remind everyone that Discourse is open sourced and therefore tweaks are 
possible. If you prefer a consistent font like on swift.org, than spell it out 
and help to create a corner on the web where every Swiftier feels right at 
home. 


I don’t think that Discourse is salvageable but go on. But I don’t know how one 
could rip out this big piece of JavaScript and keep ist functional.
Personally I’d prefer (if possible) that we’d remove profile pictures from the 
forum and simply have only full names (colored?) + some kind of annotation 
(e.g. Core Team, etc.). Profile pictures are only gimmicks that does not 
contribute to anything at all.

As Jan already said, the font (and font-size?) of the forum could match the 
font from swift.org if possible. I wouldn’t mind and it’d make it a little bit 
more alike.


You don’t have to care for me - Swift 4 will be the deciding step if I throw 
any Swift work away and return to Objective-C. The heavy functional programming 
push since open sourcing is so annoying and made Swift imo a worse language.

Jan
___
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-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Jens Alfke via swift-evolution]

> On Feb 9, 2017, at 3:41 AM, Jan Neumüller via swift-users 
>  wrote:
> 
> I would prefer http://www.fudforum.org/  that has 
> good mailing list support, too.

Well, we appear to have completely opposite opinions on UI/usability. I took a 
look at fudforum and yeah, to my eyes it exemplifies the awful clutter that’s 
been a hallmark of web forums since before PHPBB. There’s so much visual noise 
it’s very hard to parse or to find anything. Clearly designed by a coder with a 
big hammer named “”. I’m not a UI designer, but I’ve worked extensively 
with UI designers (I spent 15 years at Apple working on stuff like iChat and 
AppleScript) so I think I have some grounding in the field.

I do believe, though, that whatever solution swift.org  
switches to needs to have good email support. That way the people who hate the 
web UI, or who just don’t prefer to use the web for discussions, can keep using 
email as we do today. This is perfectly feasible to do; again, groups.io 
 is a good example. 

Here my concern is that I have not found a way to configure Discourse to make 
its email notifications work well as a substitute for a mailing list. I have 
admin privileges on a Discourse installation run by my employer, so I’ve looked 
through the entire admin UI for ways to improve the emails, and some of the 
problems don’t seem fixable by tweaking settings.

At this point I’m going to shut up because it sounds like the decision has been 
made, and I don’t want to contribute to further bike-shedding.

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

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Matthew Johnson via swift-evolution]

> On Feb 9, 2017, at 10:33 AM, Adrian Zubarev  
> wrote:
> 
> The last explanation is great, now I could follow the idea behind the 
> proposed closed keyword/access modifier. I do now understand the contract on 
> enums, but I’m struggling to understand how closed would work in my own 
> codebase. Assume I had a closed (not the public meaning of your proposal) 
> protocol.
> 
> Am I allowed to conform to that protocol inside my library? If it’s a version 
> controlled feature, how to prevent further conformance to that protocol in a 
> newer version?
> 
Yes, you are allowed to have as many conforming types inside the library as you 
wish, as long as the conformances are introduced alongside the protocol.  New 
conformances may not be added in future versions.

I don’t know exactly what the enforcement mechanism would look like, but I 
imagine it would be similar or identical to the mechanism used for `closed` 
enums.  Maybe someone from the core team can elaborate on what this will look 
like.
> What would an access modifier like closed mean on type members (final 
> public)? If it’s only a type scope access modifier, it leans towards being an 
> attribute instead.
> 
I hadn’t considered this yet but it’s a good question.  I don’t have time to 
consider it deeply, but I think the implication for members is that all 
overrides are public and no new overrides will be added in the future.  It 
isn’t likely to be useful in this case, but I think we could provide a clear 
definition.
> If it’s not an access modifier, would closed have some versioning paramerters?
> Bikeshedding: @closed(1.0.0) (The version, the type was closed)
> On current enums: @closed(*) (From the start)
Good question.  This is what the Library Evolution document has to say:

@closed is a versioned attribute. This is so that clients can deploy against 
older versions of the library, which may have non-public cases in the enum. (In 
this case the client must manipulate the enum as if the @closed attribute were 
absent.) All cases that are not versioned become implicitly versioned with this 
number.

I would prefer to see `closed` be an access modifier so it isn’t penalized with 
verbosity, particularly for enums.  I think the best approach is that `closed` 
with no version specifier is allowed if it is included in the initial release 
of a module.  `public` enums may be changed to `closed(n.m.x)` in future 
versions of a module.  There is already precedent for parameterized access 
modifiers: `private(set)`.

> The latter implies in my head that each type needs an explicit version 
> annotation like @available(1.0.0, *)!?
> 
No, I don’t think so.
> How do we handle bug fixes on closed types? Assume all current enums would 
> get an annotation like @closed(*) public. After normalize enum case 
> representation proposal 
> 
>  you might also want to clean up the names of your cases. That means you have 
> to perform a breaking API change.
Both proposals would be part of Swift 4. No module would be able to publish a 
production-ready version until Swift 4 is released.  Also, `closed` wouldn’t 
have ABI implications until ABI is locked down, which won’t happen until Swift 
4 is released (or later).  So you would have the chance to clean up case names 
at the same time as you introduce `closed`.

It’s also worth pointing out that changing a case name is going to be a 
breaking change regardless of whether an enum is `closed` or not.  It might be 
possible to minimize the impact of these changes if there was a way to specify 
the prior, deprecated name for the case, but this issue is orthogonal to 
`closed`.
> For example in one of my ‘just for fun’ projects I have two enum cases that 
> look as follows:
> 
> case javaScript(String)
> case scopedJavaScript(String, scope: Document)
> If the mentioned proposal will be accepted I’d like to make these cases shiny.
> 
> // v1:
> case javaScript(String)
> case javaScript(String, scope: Document)
>  
> // or v2:
> case javaScript(String, scope: Document? = nil)
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 9. Februar 2017 um 16:57:40, Matthew Johnson via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> 
>>> On Feb 8, 2017, at 5:48 PM, Xiaodi Wu >> > wrote:
>>> 
>>> I agree very much with rationalizing access levels, but I'm not sure I like 
>>> this proposal for public vs. closed. How would the compiler stop me from 
>>> editing my own code if something is closed? The answer must be that it 
>>> can't, so I can't see it as a co-equal to open but rather simply a 
>>> statement of intention. Therefore I think use cases for the proposed 
>>> behavior of closed would be better served by annotations and proper 
>>> semantic versioning.
>> 
>> The most important point IMO is th

Re: [swift-evolution] SE-0152: Package Manager Tools Version

[Will Field-Thompson via swift-evolution]

> 
> Is there a particular reason you're envisioning that we might need to extend 
> the metadata for the Swift tools version?

I can't think of any reason myself, I just noticed the escape hatch and was 
wondering if there were any planned uses for it!

> We've left ourself an escape hatch in case we ever do need to, where anything 
> after a  ';' character in the tools version comment will be ignored for now, 
> but I'm not expecting that we'll ever need to use that escape hatch. The 
> Swift tools version itself needs to be stored in a special way since it 
> dictates how we'll interpret the manifest, but once we've determined that, 
> all other data should be able to be stored as Swift code in the manifest as 
> per usual.

Given that, I think the comment in Package.swift is almost definitely the right 
way to go.

> If you can think of some good reasons why we'd actually need this 
> extensibility, please do suggest them. Otherwise I'd hope that we wouldn't 
> need to choose a less convenient mechanism here for the sake of more 
> convenient extensibility that will likely never be used.

I completely agree. Thank you for explaining!

- Will


> Thanks,
> 
>   - Rick
> 
>>> On Feb 8, 2017, at 10:49 AM, Will Field-Thompson via swift-evolution 
>>>  wrote:
>>> 
>>>  
>>> *  What is your evaluation of the proposal?
>> 
>> I fully support the goals of the proposal and have a question about the 
>> implementation.
>> 
>>> 
>>> *  Is the problem being addressed significant enough to warrant a 
>>> change to Swift?
>> 
>> Yep. It provides a good way to evolve the API, and putting it in place for 
>> Swift 3.1 gives us the freedom to evolve the API as (or if) needed for Swift 
>> 4.
>> 
>>> *  Does this proposal fit well with the feel and direction of Swift?
>> 
>> I agree that the placement of the tools version in a comment is unfortunate, 
>> but I think that it's the best way to include it in Package.swift.
>> 
>> I'm interested in other people's thoughts on a .swift-tools-version file. 
>> I'm not sure I prefer it to the comment in Package.swift, but the reasons 
>> included in the proposal don't convince me the .swift-tools-version 
>> shouldn't be used either.
>> Eliminates the possibility of including either Package.swift or 
>> .swift-tools-version: Seems like exactly the kind of mistake you make once 
>> and then don't make again. I guess with a leading dot it's more likely to be 
>> forgotten than a non-dot-file, but not a major issue IMO.
>> Users may like to see the version in the Package.swift: Probably true, 
>> though I'm not sure how much of an issue it is.
>> Are these significant problems for other people? They don't seem that way to 
>> me, but I may not represent the majority here as my work is in iOS dev and 
>> the only time I get to use swiftpm is for side projects. 
>> 
>> The .swift-tools-version has the advantage that it is extendable in a 
>> prettier (i.e. easier to read and easier to diff for VCS purposes) way than 
>> the semicolon-separated syntax from the proposal. How likely is it that 
>> we'll ever have to extend it? I think that, for me, is the determining 
>> factor for which format I prefer.
>> 
>>> *  If you have used other languages or libraries with a similar 
>>> feature, how do you feel that this proposal compares to those?
>> 
>> The main package manager I use is CocoaPods and as far as I am aware 
>> CocoaPods doesn't allow you to specify the tools version in the Podfile. 
>> This did cause some (albeit minimal) pain on transition to CocoaPods 1.0. I 
>> think Podfile.lock records the version of CocoaPods, but I don't think that 
>> actually helps in this regard.
>> 
>>> *  How much effort did you put into your review?  A glance, a quick 
>>> reading, or an in-depth study?
>>  
>> I spent some time reading through the proposal, but I lost track of the 
>> discussion pre-proposal.
>> 
>> - Will
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Adrian Zubarev via swift-evolution]

The last explanation is great, now I could follow the idea behind the proposed 
closed keyword/access modifier. I do now understand the contract on enums, but 
I’m struggling to understand how closed would work in my own codebase. Assume I 
had a closed (not the public meaning of your proposal) protocol.

Am I allowed to conform to that protocol inside my library? If it’s a version 
controlled feature, how to prevent further conformance to that protocol in a 
newer version?

What would an access modifier like closed mean on type members (final public)? 
If it’s only a type scope access modifier, it leans towards being an attribute 
instead.

If it’s not an access modifier, would closed have some versioning paramerters?
Bikeshedding: @closed(1.0.0) (The version, the type was closed)
On current enums: @closed(*) (From the start)
The latter implies in my head that each type needs an explicit version 
annotation like @available(1.0.0, *)!?

How do we handle bug fixes on closed types? Assume all current enums would get 
an annotation like @closed(*) public. After normalize enum case representation 
proposal you might also want to clean up the names of your cases. That means 
you have to perform a breaking API change.
For example in one of my ‘just for fun’ projects I have two enum cases that 
look as follows:

case javaScript(String)
case scopedJavaScript(String, scope: Document)
If the mentioned proposal will be accepted I’d like to make these cases shiny.

// v1:
case javaScript(String)
case javaScript(String, scope: Document)
 
// or v2:
case javaScript(String, scope: Document? = nil)


-- 
Adrian Zubarev
Sent with Airmail

Am 9. Februar 2017 um 16:57:40, Matthew Johnson via swift-evolution 
(swift-evolution@swift.org) schrieb:


On Feb 8, 2017, at 5:48 PM, Xiaodi Wu  wrote:

I agree very much with rationalizing access levels, but I'm not sure I like 
this proposal for public vs. closed. How would the compiler stop me from 
editing my own code if something is closed? The answer must be that it can't, 
so I can't see it as a co-equal to open but rather simply a statement of 
intention. Therefore I think use cases for the proposed behavior of closed 
would be better served by annotations and proper semantic versioning.

The most important point IMO is that they *are* co-equal in the sense that they 
define a contract between library authors, library users and the compiler.  As 
you note, there are some differences in how the `closed` contract is supported. 
 But that is far less important than the meaning of the contract itself.

Dave's comment about tools to assist with contract-compatible API evolution is 
the right way to think about this.  Of course you *can* make breaking changes, 
but we want to make it clear when you *are* making a breaking change, both for 
source and for ABI compatibility.  This will help library authors, but it also 
helps users as well as the compiler reason about code when we are able to offer 
stronger guarantees.

Most notably, the behavior of public enums *already* has the API contract of 
`closed` and we do not want to remove that capability.  This proposal only 
formalizes how that contract is specified and makes it consistent across all 
kinds of types.  It *does not* introduce the idea of a closed semantic contract 
for a type.

As this change didn't seem in scope for Swift 4 phase 1, I've held off on 
discussing my own thoughts on access levels. The idea I was going to propose in 
phase 2 was to have simply open and public enums (and protocols). I really 
think that completes access levels in a rational way without introducing 
another keyword.

The reason I posted now is because formalizing this API contract for enums must 
happen before ABI is locked down, and also because there is at least one 
protocol in the standard library (`MirrorPath`) which is documented with the 
intent that it be `closed`.

I understand the reluctance to introduce another keyword.  It isn’t clear to me 
what semantics you assign to `open` and `public` enums.

Are you suggesting that they match the semantics defined in my proposal and 
suggesting closed enums (i.e. matching the current behavior of `public` enums) 
would require an `@closed` annotation as suggested in the Library Evolution 
document?  I am opposed to this approach because it penalizes the API contract 
that I think is often the most appropriate for enums.  I strongly prefer that 
we adopt the same neutral stance that we when we introduced `open`.  

On the other hand, you might be suggesting that `public` enums maintain their 
current behavior and we simply introduce `open` as a modifier that reserves the 
right for the *library* to introduce new cases while continuing to prohibit 
*users* from introducing new cases.  This approach has inconsistent semantics 
for both `public` and `open`.  These keywords would indicate a different API 
contract for enums than they do for classes and protocols.  In fact, `open` for 
enums would

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Matthew Johnson via swift-evolution]

> On Feb 8, 2017, at 7:02 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Hurray, I cannot wait to get the consistent behavior of open/public 
> protocols. I’m not sure I could follow the idea behind the proposed closed 
> keyboard/access modifier. It almost felt like closed == final public, am I 
> mistaken something here?
> 


The best way to think about `closed` is to just think about `public enum` as it 
exists today.  The contract implies that no new cases will be added because 
user code is allowed to perform exhaustive switch over the cases.  Adding a 
case is a breaking change.

The insight behind this proposal is that we can also support these semantics 
with classes and protocols.  A `closed` class may have subclasses within the 
module so long as they are public, but no direct subclasses may be added in 
future versions (descendants may still be added if the `closed` class has a 
non-final subclass).  Adding a subclass in the future becomes a breaking change.

Similarly with protocols, no new conformances will be added in future versions 
of the library.  As with `closed` classes, if a non-final class conforms to a 
`closed` protocol subclasses may still be added in the future.

The relationship between `closed` and `final public` is interesting.  `final 
public` is equivalent to `final closed` under this proposal as long as the 
semantics of `final` implies not only that there are no subclasses *right now*, 
but also that  that no subclasses will ever be added *in the future*.  This is 
the semantics suggested in the Library Evolution document - "final may not be 
removed from a class or its members. (The presence of final enables 
optimization.)”.  This is a degenerate case of `closed`: new subclasses cannot 
be added because `final` declares that there will *never be* any subclasses.
> Furthermore, I really would love if the community could revisit how 
> open/public really should behave. When open was implemented and I tried it 
> out without reading the proposal first I bumped into things like open init() 
> which felt really odd. I understand the argumentation from the proposal, but 
> it feels wrong and inconsistent to me.
> 
> Here’s how I would have imagined open vs. public. IMHO public should really 
> mean, you cannot subclass, conform or override something in module B from 
> module A.
> 
> Modified samples from SE–0117:
> 
> // This class is not subclassable outside of ModuleA.
> public class NonSubclassableParentClass {
> // This method >is not overridable outside of ModuleA.
> public func foo() {}
> 
> // This method is not overridable outside of ModuleA because
> // its class restricts its access level.
> // It is INVALID to declare it as `open`.
> public func bar() {}
> 
> // The behavior of `final` methods remains unchanged.
> public final func baz() {}
> }
> 
> // This class is subclassable both inside and outside of ModuleA.
> open class SubclassableParentClass {
>  
> // Designated initializer that is not overridable outside ModuleA
> public init()
>  
> // Another designated initializer that is overridable outside ModuleA
> open init(foo: Int)
>  
> // This property is not overridable outside of ModuleA.
> public var size : Int
> 
> // This method is not overridable outside of ModuleA.
> public func foo() {}
> 
> // This method is overridable both inside and outside of ModuleA.
> open func bar() {}
> 
> /// The behavior of a `final` method remains unchanged.
> public final func baz() {}
> }
> 
> /// The behavior of `final` classes remains unchanged.
> public final class FinalClass { }
> /// ModuleB:
> 
> import ModuleA
> 
> // This is allowed since the superclass is `open`.
> class SubclassB : SubclassableParentClass {
>  
> // Iff certain conditions are met, the superclass initializers are 
> inherited.
> // `init` will stay `public` and won't be overridable.
> //
> // If the conditions are not met, then `init` is not inherited. That does 
> not
> // mean that we can create a new designated `init` that matches it's 
> superclass's
> // designated initializer. The behavior should be consistent, like the  
> // superclass's function `foo` is reserved and not overridable, so is 
> `init`
> // reserved in this case and not overridable.
>  
> // This is allowed since the superclass's initializer is `open`
> override init(foo: Int) {
> super.init(foo: foo)
> }
>  
> init(bar: Int) {
> // We could call a super designated initializer from here
> super.init()
> // or
> super.init(foo: bar)
> }
>  
> // This is invalid because it overrides a method that is
> // defined outside of the current module but is not `open'.
> override func foo() { }
> 
> // This is allowed since the superclass's method is overridable.
> // It does not need to be marked `open` becaus

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Matthew Johnson via swift-evolution]

> On Feb 8, 2017, at 5:48 PM, Xiaodi Wu  wrote:
> 
> I agree very much with rationalizing access levels, but I'm not sure I like 
> this proposal for public vs. closed. How would the compiler stop me from 
> editing my own code if something is closed? The answer must be that it can't, 
> so I can't see it as a co-equal to open but rather simply a statement of 
> intention. Therefore I think use cases for the proposed behavior of closed 
> would be better served by annotations and proper semantic versioning.

The most important point IMO is that they *are* co-equal in the sense that they 
define a contract between library authors, library users and the compiler.  As 
you note, there are some differences in how the `closed` contract is supported. 
 But that is far less important than the meaning of the contract itself.

Dave's comment about tools to assist with contract-compatible API evolution is 
the right way to think about this.  Of course you *can* make breaking changes, 
but we want to make it clear when you *are* making a breaking change, both for 
source and for ABI compatibility.  This will help library authors, but it also 
helps users as well as the compiler reason about code when we are able to offer 
stronger guarantees.

Most notably, the behavior of public enums *already* has the API contract of 
`closed` and we do not want to remove that capability.  This proposal only 
formalizes how that contract is specified and makes it consistent across all 
kinds of types.  It *does not* introduce the idea of a closed semantic contract 
for a type.

> As this change didn't seem in scope for Swift 4 phase 1, I've held off on 
> discussing my own thoughts on access levels. The idea I was going to propose 
> in phase 2 was to have simply open and public enums (and protocols). I really 
> think that completes access levels in a rational way without introducing 
> another keyword.

The reason I posted now is because formalizing this API contract for enums must 
happen before ABI is locked down, and also because there is at least one 
protocol in the standard library (`MirrorPath`) which is documented with the 
intent that it be `closed`.

I understand the reluctance to introduce another keyword.  It isn’t clear to me 
what semantics you assign to `open` and `public` enums.

Are you suggesting that they match the semantics defined in my proposal and 
suggesting closed enums (i.e. matching the current behavior of `public` enums) 
would require an `@closed` annotation as suggested in the Library Evolution 
document?  I am opposed to this approach because it penalizes the API contract 
that I think is often the most appropriate for enums.  I strongly prefer that 
we adopt the same neutral stance that we when we introduced `open`.  

On the other hand, you might be suggesting that `public` enums maintain their 
current behavior and we simply introduce `open` as a modifier that reserves the 
right for the *library* to introduce new cases while continuing to prohibit 
*users* from introducing new cases.  This approach has inconsistent semantics 
for both `public` and `open`.  These keywords would indicate a different API 
contract for enums than they do for classes and protocols.  In fact, `open` for 
enums would have a contract analagous with `public` for classes and protocols.  
This feels like a recipe for confusion.  IMO, having consistent semantics for 
each keyword is pretty important.  We already have, and desire to continue to 
have, three distinct semantic contracts.  If we want keywords with consistent 
semantics we are going to have to introduce a new keyword for the third meaning.


> On Wed, Feb 8, 2017 at 17:05 Matthew Johnson via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> I’ve been thinking a lot about our public access modifier story lately in the 
> context of both protocols and enums.  I believe we should move further in the 
> direction we took when introducing the `open` keyword.  I have identified 
> what I think is a promising direction and am interested in feedback from the 
> community.  If community feedback is positive I will flesh this out into a 
> more complete proposal draft.
> 
> 
> Background and Motivation:
> 
> In Swift 3 we had an extended debate regarding whether or not to allow 
> inheritance of public classes by default or to require an annotation for 
> classes that could be subclassed outside the module.  The decision we reached 
> was to avoid having a default at all, and instead make `open` an access 
> modifier.  The result is library authors are required to consider the 
> behavior they wish for each class.  Both behaviors are equally convenient 
> (neither is penalized by requiring an additional boilerplate-y annotation).
> 
> A recent thread 
> (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031566.html
>  
> )
>  discussed a similar tradeoff 

Re: [swift-evolution] Strings in Swift 4

[Ben Cohen via swift-evolution]

> On Feb 9, 2017, at 7:48 AM, Shawn Erickson via swift-evolution 
>  wrote:
> 
> I also wonder what folks are actually doing that require indexing into 
> strings. I would love to see some real world examples of what and why 
> indexing into a string is needed. Who is the end consumer of that string, etc.
> 
> Do folks have so examples?

Big +1 for this. Real world use cases that are hard today would be great to see 
so we can make sure they are accounted for in the new API design.

The ideal situation is that there is a common pattern with many of them that 
can be accommodated through useful higher-level methods (maybe even on 
Collection) that avoid the need to mess around with indices.


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

Re: [swift-evolution] Strings in Swift 4

[Shawn Erickson via swift-evolution]

I also wonder what folks are actually doing that require indexing into
strings. I would love to see some real world examples of what and why
indexing into a string is needed. Who is the end consumer of that string,
etc.

Do folks have so examples?

-Shawn

On Thu, Feb 9, 2017 at 6:56 AM Ted F.A. van Gaalen via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Hooman
> That invalidates my assumptions, thanks for evaluating
> it's more complex than I thought.
> Kind Regards
> Ted
>
> On 8 Feb 2017, at 00:07, Hooman Mehr  wrote:
>
>
> On Feb 7, 2017, at 12:19 PM, Ted F.A. van Gaalen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I now assume that:
>   1. -= a “plain” Unicode character (codepoint?)  can result in one
> glyph.=-
>
>
> What do you mean by “plain”? Characters in some Unicode scripts are by no
> means “plain”. They can affect (and be affected by) the characters around
> them, they can cause glyphs around them to rearrange or combine (like
> ligatures) or their visual representation (glyph) may float in the same
> space as an adjacent glyph (and seem to be part of the “host” glyph), etc.
> So, the general relationship of a character and its corresponding glyph (if
> there is one) is complex and depends on context and surroundings characters.
>
>   2. -= a  grapheme cluster always results in just a single glyph,
> true? =-
>
>
> False
>
>   3. The only thing that I can see on screen or print are glyphs
> (“carvings”,visual elements that stand on their own )
>
>
> The visible effect might not be a visual shape. It may be for example, the
> way the surrounding shapes change or re-arrange.
>
>  4.  In this context, a glyph is a humanly recognisable visual form of
> a character,
>
>
> Not in a straightforward one to one fashion, not even in Latin / Roman
> script.
>
>  5. On this level (the glyph, what I can see as a user) it is not
> relevant and also not detectable
>  with how many Unicode scalars (codepoints ?), grapheme, or even
> on what kind
>  of encoding the glyph was based upon.
>
>
> False
>
>
> ___
> 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] Protocol requirement `where` clauses constraining associated types

[Douglas Gregor via swift-evolution]

> On Feb 8, 2017, at 11:12 PM, Slava Pestov  wrote:
> 
>> 
>> On Feb 8, 2017, at 10:30 PM, Douglas Gregor  wrote:
>> 
>> 
>>> On Feb 8, 2017, at 10:21 PM, Slava Pestov  wrote:
>>> 
>>> Hah, Doug and I were just discussing this.
>>> 
>>> In Swift 3.1, we generalized where clauses to allow them to add 
>>> requirements on outer generic parameters. However we did not remove the 
>>> diagnostic prohibiting a where clause from being attached to a non-generic 
>>> method. In theory this can be made to work; the only slightly tricky thing 
>>> is we will get a GenericParamList with zero parameters but non-zero 
>>> requirements, which would require shuffling some things around to avoid 
>>> assertions.
>>> 
>>> This would be a good starter project for someone who wanted to learn more 
>>> about the generics system.
>>> 
>>> As for index(of:) and the specific details of the stdlib that are involved 
>>> here, I have no idea — I’m just talking about the bogus diagnostic itself.
>> 
>> Well, I think Brent is talking about doing this on a protocol requirement, 
>> which is more interesting because not all conforming types would satisfy the 
>> requirement…
> 
> Since there would be no way to invoke the requirement on such a type, could 
> we leave the entry blank in the witness table or emit a fatalError() thunk or 
> something?

I’d previously thought so, but retroactive modeling makes this more interesting 
than that:

// Module A
public protocol P { }
public protocol Q {
  associatedtype Assoc

  func f() where Assoc: P
}

public struct X { }

public struct Y : Q {
  public typealias Assoc = X

  // X doesn’t conform to P, so I guess we can omit f()?
}

public func callF(t: T) where T.Assoc: P {
  t.f()  // should be allowed to call f() because we know that T.Assoc 
conforms to P
}

// Module B
public extension X: P { }

callF(Y()) // BOOM at runtime, because witness table Y: Q doesn’t 
include f!


So, I think that means we can’t just leave a stub there

// Back in module A
public struct Z : Q {
  public typealias Assoc = X

  public func f() where X: P { }  // wait, what?
}

That last one is “fun”. The method “f()" is only available when the concrete 
type X conforms to P. We know it doesn’t right now—but it could in the future. 
It’s a bit odd to reason about such a function, because you’re evaluating how 
the concrete type X would behave if it did in fact conform to P! In 
Swift-compiler-speak, it’s a concrete type with an abstract conformance to P, 
which is a bit of a model breaker.

- Doug

> 
> Slava
> 
>> 
>>  - Doug
>> 
>>> 
>>> Slava
>>> 
 On Feb 8, 2017, at 9:57 PM, Brent Royal-Gordon via swift-evolution 
  wrote:
 
 In an article on `Collection` today*, Ole Begemann points out that 
 `index(of:)`, along with other `Equatable`- and `Comparable`-constrained 
 `Collection` methods, cannot be overridden. Actually, it *can* be, but 
 only through a private mechanism—there's a 
 `_customIndexOfEquatableElement(_:)` method that's invisible in the 
 generated interface. But that only proves the need for a way to make 
 methods like these overridable.
 
 The problem is that the `index(of:)` method should only be offered when 
 the element is `Equatable`—otherwise it simply won't work. But there's no 
 way to specify this rule in current Swift. In theory, we could describe 
 such a requirement with something like this:
 
func index(of element: Iterator.Element) -> Index? where 
 Iterator.Element: Equatable
 
 But this is not permitted—you get an error indicating that `where` clauses 
 are only allowed on generic methods. Adding a spurious generic parameter 
 allows this code to compile, but with a deprecation warning indicating 
 that this is deprecated. I don't know if it would actually behave 
 correctly, however.
 
 Is this a feature we should add? Is this the way to add it? Would it have 
 non-additive ABI impact? (The private `index(of:)` override would 
 certainly go away, but that's why it's private, I suppose.) I don't seem 
 to remember seeing something like this in the generics manifesto, so I 
 thought it was worth bringing up.
 
 
 
 * https://oleb.net/blog/2017/02/sorted-array/
 
 -- 
 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] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Jan Neumüller via swift-evolution]

Well, if the community likes it so much. Have fun with it. I will leave as I 
have left the Developer Forums at Apple because they became unusable.


> On 9 Feb 2017, at 15:17, Adrian Zubarev  
> wrote:
> 
> The quote below made my day dear Swift friend as I might remind you that if 
> modern is associated with hate in your mind, then the modern programming 
> language called Swift would probably be a bad choice. 
> 
> 
I starting to think that myself. I was very active at the beginning of Swift 
(way before the open sourcing) but I absolutely don’t like the increasing 
influence of functional programming on it. I despise fp and don’t want it in 
Swift. If people want it that much use Haskell 8(
> I might remind everyone that Discourse is open sourced and therefore tweaks 
> are possible. If you prefer a consistent font like on swift.org 
> , than spell it out and help to create a corner on the web 
> where every Swiftier feels right at home. 
> 
> 
I don’t think that Discourse is salvageable but go on. But I don’t know how one 
could rip out this big piece of JavaScript and keep ist functional.
> Personally I’d prefer (if possible) that we’d remove profile pictures from 
> the forum and simply have only full names (colored?) + some kind of 
> annotation (e.g. Core Team, etc.). Profile pictures are only gimmicks that 
> does not contribute to anything at all.
> 
> As Jan already said, the font (and font-size?) of the forum could match the 
> font from swift.org  if possible. I wouldn’t mind and it’d 
> make it a little bit more alike.
> 
> 
You don’t have to care for me - Swift 4 will be the deciding step if I throw 
any Swift work away and return to Objective-C. The heavy functional programming 
push since open sourcing is so annoying and made Swift imo a worse language.

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

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

[Jan Neumüller via swift-evolution]

> On 9 Feb 2017, at 13:50, Adrian Zubarev  
> wrote:
> 
> That last one is horrible to even look at (that’s my personal point of view). 
> It’s packed full with unnecessary UI, which reminds me of the time when 
> html-tables ruled all over the place. Discourse has a nice minimalistic look 
> and I’m sure people that will setup the forum will tweak it to make it feel 
> more appropriate for Swift, just like the design of the evolution-page was 
> tweaked several times. 
> 
I don’t see unnecessary UI, I see NEEDED UI. Discourse is so minimalistic you 
don’t see any relevant information at all 8(

> Here is really good example of how a huge/popular topic like the current one 
> or String in Swift 4 would look like with Discourse (I picked one from Rust 
> with lots of replies): 
> https://users.rust-lang.org/t/high-order-function-with-type-parameter/3112/ 
> 
> +1 for Discourse, I think it really is the right choice.
> 
What is good at this example? I don’t see anything good there but lots of 
problems:

- very hard to see who posted a reply
- very bad readability thanks to tiny font and low contrast colors
- totally broken threading (is one really supposed to click each time on 
replies to see them?)
- lots of wasted screen space (empty space and a very narrow text area)
- cryptic stuff like this 
https://www.dropbox.com/s/6a9fyuin4yyp5u8/Screenshot%202017-02-09%2014.03.20.png?dl=0
 

- endless scrolling…

This is considered GOOD today? Does any modern web trend think on older people 
and people with glasses anymore?

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

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

[Jan Neumüller via swift-evolution]

> On 9 Feb 2017, at 14:32, Adrian Zubarev  
> wrote:
> 
> I’m sorry for you, but I don’t think we’re talking in this thread about being 
> old and wearing glasses or not. My eyes aren’t the best either, but I’m not 
> complaining about that or try to make this as an argument against 
> minimalistic designs. (Coloring is a different story of its own.)
> 
> 
I hate “modern” or as I call it ugly web design.

> How’s that needed UI at all? It’s an ugly piece of web art compared to these 
> days standards. 
> 
> 
Everything making functions and structure clearer is good. Today’s standards 
are a bag of pain and I never understood how such crappy sites als Facebook, 
Twitter, Instagram, Stackoverflow, add lots of other “cool” sites are liked by 
so many. For me they are the epitome of what is wrong with todays web.

> What’s the problem with endless scrolling? We’re all doing that every day on 
> the internet, scrolling down to find and click on the next or # button for 
> the purpose to again being able to scroll down to click on the same button 
> over and over again. Discourse took that unnecessary click from you and 
> provides a nice side scroller to quickly jump to a specific reply you want.
> 
> 
I can’t stand scrolling. Pages and pageturning are much nicer to my eyes and 
mind. I always lose track in these endless scrolling nightmares.

> Reading all your complains lets me think that it’s exactly how you would 
> think about sites like stackoverflow for example (or even the minimalistic 
> swift.org ).
> 
> 
Se above - I hate both. At least swift.org  has a font in 
readable size.

For me even the old geocities chaos was nicer then todays minimalistic crap. 
But I may possible thats my age, I hate modern music and movies, too.

> I’m not trying to be offensive by any means. I just criticized your choice 
> from my esthetic point of view.
> 
> 
And I’m just frustrated at this downward spiral in useful and nice design. It’s 
like the iOS Music app  - gone from a nice and very useful app (till iOS6) to 
todays absolutely useless crap that tries to forcefeed Apple Music onto me but 
doesn’t help in efficient handling of my own music library. Luckily I could 
switch to Caesium to fix that.

Jan

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

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

[Jan Neumüller via swift-evolution]

My problem with Discourse lies in its terrible ui. It  is like most modern 
social media: totally useless to find stuff and stay organized in it. It 
reminds my heavy on the terrible ui of Facebook and the redone developer forums 
at Apple that have gone from fine to utterly useless chaos. Perhaps I’m to old 
for modern web, but what are other finding great at this?

I would prefer http://www.fudforum.org/  that has 
good mailing list support, too.

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

Re: [swift-evolution] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

Hello Hooman
That invalidates my assumptions, thanks for evaluating
it's more complex than I thought.
Kind Regards
Ted

> On 8 Feb 2017, at 00:07, Hooman Mehr  wrote:
> 
> 
>> On Feb 7, 2017, at 12:19 PM, Ted F.A. van Gaalen via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> I now assume that:
>>   1. -= a “plain” Unicode character (codepoint?)  can result in one 
>> glyph.=-
> 
> What do you mean by “plain”? Characters in some Unicode scripts are by no 
> means “plain”. They can affect (and be affected by) the characters around 
> them, they can cause glyphs around them to rearrange or combine (like 
> ligatures) or their visual representation (glyph) may float in the same space 
> as an adjacent glyph (and seem to be part of the “host” glyph), etc. So, the 
> general relationship of a character and its corresponding glyph (if there is 
> one) is complex and depends on context and surroundings characters.
> 
>>   2. -= a  grapheme cluster always results in just a single glyph, true? 
>> =- 
> 
> False
> 
>>   3. The only thing that I can see on screen or print are glyphs 
>> (“carvings”,visual elements that stand on their own )
> 
> The visible effect might not be a visual shape. It may be for example, the 
> way the surrounding shapes change or re-arrange.
> 
>>  4.  In this context, a glyph is a humanly recognisable visual form of a 
>> character,
> 
> Not in a straightforward one to one fashion, not even in Latin / Roman script.
> 
>>  5. On this level (the glyph, what I can see as a user) it is not 
>> relevant and also not detectable
>>  with how many Unicode scalars (codepoints ?), grapheme, or even on 
>> what kind
>>  of encoding the glyph was based upon.
> 
> False
> 

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

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

[Martin Man via swift-evolution]

Is there any reason why there needs to be a separate tool for this?

If mailing lists are no go why not just stay on GitHub and use GitHub issues 
for proposals?

Thanks,
Martin

> On 9 Feb 2017, at 08:51, Jens Alfke via swift-users  
> wrote:
> 
> 
>> On Feb 8, 2017, at 4:48 PM, Jan Neumüller via swift-users 
>> mailto:swift-us...@swift.org>> wrote:
>> 
>> May I ask why with so many great open source forums that junk Discourse got 
>> chosen? I'm very perplexed by this decision...
> 
> I’ve looked at a lot of forum software, and most of the open-source ones are 
> pretty poor* in terms of UI and usability.
> Discourse is very good as a web app, although its email integration doesn’t 
> work that well IMHO, so it’s not really a direct replacement for a mailing 
> list.
> If I were proposing something, I’d propose groups.io . 
> (Which is also not open source, sorry.)
> 
> —Jens
> 
> * I’m being diplomatic. Many of them are worse than poor. The word “wretched” 
> comes to mind.
> ___
> swift-users mailing list
> swift-us...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

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

[Karl Wagner via swift-evolution]

  
  
Happy dance! 🎉🕺🎉
  
  
  

  
I've said before that I think this a good move. Hopefully it encourages more 
ad-hoc contributions - e.g. Unicode experts who have suggestions for the String 
model, Perl developers with suggestions for pattern-matching, systems 
architects with suggestions for the memory model, etc. That's what open-source 
is all about, IMO. Maybe somebody they know notices the discussion - with this 
they'll have a convenient interface to get up to speed, follow the discussion 
and chime in with their experience. I don't know if that will _actually_ happen 
or how many such developers there are, but   by lowering the barrier to 
participation   we're doing as much as we can do to encourage them.
  
  
  
 So yeah, thanks a lot!
  
  
  
 - Karl
  
  
  

  
>   
> On Feb 9, 2017 at 12:03 am,   (mailto:swift-us...@swift.org)>  wrote:
>   
>   
>   
>  Hi everyone,
>
> There was a long thread on swift-evolution about whether we should use modern 
> forum software — like Discourse — as an alternative to the mailing lists we 
> have now. After a long discussion, the Core Team has decided to move 
> swift-evolution and swift-users to Discourse.
>
> There are tradeoffs to moving to a forum. The main advantages are:
>
> - Easy for people to participate without subscribing to the entire mailing 
> list, as well as no need to provide email address to participate. A lot of 
> people have voiced concern that they feel resistance to participate because 
> of needing to subscribe to a mailing list.
>
> - Consistent affordances and rendering of content, including Markdown 
> support. This is really useful for having technical discussions.
>
> - Better searching of topics, archiving, etc.
>
> - More tools for moderation.
>
> - Topic cross-referencing, and consistent organization of topics instead of 
> whatever threading support a mail client provides (which is inconsistent).
>
> I also want to consider moving the -dev lists to the same forum setup as 
> well; but that will be a separate conversation on those lists.
>
> A rollout plan has not been figured out. People are busy and there are 
> logistics to figure out. I will be engaging a handful of members from the 
> community to help with the transition. Specifically, there are those who 
> really value using email for participation on swift-evolution and 
> swift-users, and the goal is to get the forum setup to allow those people to 
> continue to feel effective when using email for discussions on these "lists".
>
> More details will be announced as they get figured out, but I felt it was 
> important to let the community know about this direction.
>
> Ted
>
>
>
>
> ___
> swift-users mailing list
> swift-us...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>  ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

The quote below made my day dear Swift friend as I might remind you that if 
modern is associated with hate in your mind, then the modern programming 
language called Swift would probably be a bad choice.

I might remind everyone that Discourse is open sourced and therefore tweaks are 
possible. If you prefer a consistent font like on swift.org, than spell it out 
and help to create a corner on the web where every Swiftier feels right at home.

Personally I’d prefer (if possible) that we’d remove profile pictures from the 
forum and simply have only full names (colored?) + some kind of annotation 
(e.g. Core Team, etc.). Profile pictures are only gimmicks that does not 
contribute to anything at all.

As Jan already said, the font (and font-size?) of the forum could match the 
font from swift.org if possible. I wouldn’t mind and it’d make it a little bit 
more alike.



-- 
Adrian Zubarev
Sent with Airmail

Am 9. Februar 2017 um 14:57:34, Jan Neumüller via swift-users 
(swift-us...@swift.org) schrieb:

I hate “modern” or as I call it ugly web design.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

I’m sorry for you, but I don’t think we’re talking in this thread about being 
old and wearing glasses or not. My eyes aren’t the best either, but I’m not 
complaining about that or try to make this as an argument against minimalistic 
designs. (Coloring is a different story of its own.)

How’s that needed UI at all? It’s an ugly piece of web art compared to these 
days standards.

What’s the problem with endless scrolling? We’re all doing that every day on 
the internet, scrolling down to find and click on the next or # button for the 
purpose to again being able to scroll down to click on the same button over and 
over again. Discourse took that unnecessary click from you and provides a nice 
side scroller to quickly jump to a specific reply you want.

Reading all your complains lets me think that it’s exactly how you would think 
about sites like stackoverflow for example (or even the minimalistic swift.org).

I’m not trying to be offensive by any means. I just criticized your choice from 
my esthetic point of view.



-- 
Adrian Zubarev
Sent with Airmail

Am 9. Februar 2017 um 14:07:05, Jan Neumüller via swift-users 
(swift-us...@swift.org) schrieb:

I see NEEDED UI.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

That last one is horrible to even look at (that’s my personal point of view). 
It’s packed full with unnecessary UI, which reminds me of the time when 
html-tables ruled all over the place. Discourse has a nice minimalistic look 
and I’m sure people that will setup the forum will tweak it to make it feel 
more appropriate for Swift, just like the design of the evolution-page was 
tweaked several times.

Here is really good example of how a huge/popular topic like the current one or 
String in Swift 4 would look like with Discourse (I picked one from Rust with 
lots of replies): 
https://users.rust-lang.org/t/high-order-function-with-type-parameter/3112/

+1 for Discourse, I think it really is the right choice.



-- 
Adrian Zubarev
Sent with Airmail

Am 9. Februar 2017 um 12:42:04, Jan Neumüller via swift-users 
(swift-us...@swift.org) schrieb:

My problem with Discourse lies in its terrible ui. It  is like most modern 
social media: totally useless to find stuff and stay organized in it. It 
reminds my heavy on the terrible ui of Facebook and the redone developer forums 
at Apple that have gone from fine to utterly useless chaos. Perhaps I’m to old 
for modern web, but what are other finding great at this?

I would prefer http://www.fudforum.org/ that has good mailing list support, too.

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

Re: [swift-evolution] Annotation of Warnings/Errors

[Alejandro Martinez via swift-evolution]

I don't think this is a language issue, as said warnings and fix-its
are really useful.
In the other handm when watching other programmers in other languages
without IDE triggering a compile trough the terminal I see that it
allows them to put all their ideas into code first, and then deal with
warnings or errors.

The solution seems just to be "Go to preferences and select the
“General” tab. Make sure that “show live issues” is deselected". At
the end, any option to turn on or off warnings (or even show them at
specific times) should be a setting in the IDE as currently is in
Xcode.

On Sat, Feb 4, 2017 at 1:45 AM, Derrick Ho via swift-evolution
 wrote:
> I feel like warnings showing up as you type are an IDE's responsibility.
>
> Annotations to delay warnings seem like noise.  Once you get used to
> programming you don't need the annotations.
>
> If warnings are bothersome, then turn it off in the Xcode settings!
>
>
>
>
> On Thu, Feb 2, 2017 at 1:34 PM Pierre Monod-Broca via swift-evolution
>  wrote:
>>
>> +1 to the proposal
>> +1 to teach how to remove live issues to beginners, so they have a chance
>> to train at detecting errors without the compiler
>>
>>
>>
>> Pierre
>>
>> Le 2 févr. 2017 à 17:48, Nicolas Fezans via swift-evolution
>>  a écrit :
>>
>> +1
>>
>> On Tue, Jan 31, 2017 at 11:55 AM, Tino Heth via swift-evolution
>>  wrote:
>>>
>>> One of the biggest issues that I saw while teaching Swift to newbies
>>> (most had not programmed before) is confusion based on the early
>>> warnings/errors that swift/xcode gives you as they type.  What would happen
>>> is that they would type a variable, and it would say… “You haven’t used this
>>> variable” and so they would just click the fixit because they trust the
>>> compiler more than they trust themselves.  This would lead to a point where
>>> they were very confused because some of the code was code they had thought
>>> through, and some of it was changed by random fixits in ways they didn’t
>>> understand… and so it would lead to more errors/fixits until they had errors
>>> which couldn’t be fixed.
>>>
>>>
>>> Imho this is the best example to illustrate that inflationary use of
>>> warnings does more harm than good, and I hope it will be fixed.
>>>
>>> Having a bunch of conditions for warnings looks like overkill to me, and
>>> there are alternatives:
>>> - Only show when building
>>> - Only show in release builds
>>> - Linter
>>>
>>> That said, I'm going out on a limb and claim I already know how to write
>>> code and don't need basic schooling, and showing warnings before I hit
>>> compile is merely a distraction.
>>>
>>> But there are also Playgrounds which seem to be an important aspect of
>>> Swift, especially for newbies who could really benefit from some hints.
>>> There are no linters, no release builds, and even no regular builds for
>>> Playgrounds, so your model is the only one that works for them.
>>>
>>> Bottom line:
>>> +1
>>>
>>> ___
>>> 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
>



-- 
Alejandro Martinez
http://alejandromp.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] for-else syntax

[Alejandro Martinez via swift-evolution]

-1 for me.
I don't see a good enough reasons to change the language and add
another control-flow variant. I would much rather see a language
improvement that somehow allowed to implement it as a lib supporting
break/continue. Something like what Haravikk suggested.


On Tue, Feb 7, 2017 at 12:26 AM, Derrick Ho via swift-evolution
 wrote:
> I don't like the idea of for-else since it doesn't really add much value. It
> hardly saves you any typing.
>
> -1
> On Mon, Feb 6, 2017 at 6:26 PM Erica Sadun via swift-evolution
>  wrote:
>>
>>
>> On Feb 6, 2017, at 11:06 AM, Jordan Rose via swift-evolution
>>  wrote:
>>
>>
>> On Feb 6, 2017, at 02:50, Jeremy Pereira via swift-evolution
>>  wrote:
>>
>>
>> On 3 Feb 2017, at 18:00, Dave Abrahams via swift-evolution
>>  wrote:
>>
>>
>> on Fri Feb 03 2017, Dimitri Racordon  wrote:
>>
>> Talking of Python, Swift is not Python and the argument not to
>> implement a feature because its semantics conflict with the semantics
>> of a similar looking feature in another language is bogus.
>>
>>
>> I don't have a anything to say about for-else, but just a comment on the
>> meta-point of how we evaluate designs: precedent set by other languages
>> affects learnability, and is one of the criteria we've always considered
>> when designing Swift.
>>
>>
>> Two things:
>>
>> 1. Somehow the quoting in your email has got messed up so it looks like a
>> statement I made was made by somebody else who may or may not agree with the
>> sentiment expressed.
>>
>> 2. You’ve never been shy of going against precedent if you consider it to
>> be a *bad* precedent. Otherwise Swift would still have C style for loops and
>> pre/post increment/decrement operators. That is as it should be. The Python
>> for … else statement is a mess. My brief survey of the Internet suggests it
>> is confusing even to some Python programmers. It should not be allowed to
>> prevent the Swift team from implementing similarly named but better designed
>> features if there are other good reasons for doing so.
>>
>>
>> This is not at odds with what you’re saying, but I wanted to add that
>> there’s a difference between removing syntax and having conflicting syntax.
>> That is, not having a for-else loop is fine, but having a for-else loop that
>> behaves differently than Python’s would require a pretty strong reason. As
>> far as I know there’s only one place where we deliberately chose to conflict
>> with another language’s precedent, and that’s '…' being an inclusive range
>> (where it is the exclusive range operator in Ruby), and that discussion led
>> to us picking '..<‘ instead of ‘..’ for the other operator.
>>
>> Jordan
>>
>>
>> And despite disliking the updated .../..< operators at first, I find it
>> has increased
>> inspectability and clarity at the point of use. Good call in my opinion.
>> Similar behaviors and outcomes should adopt conventional syntax unless
>> an updated syntax offers measurable benefits.
>>
>> -- E
>>
>> Mildly interesting reference:
>> https://mail.python.org/pipermail/python-ideas/2009-October/006155.html
>>
>>
>>
>>
>> ___
>> 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
>



-- 
Alejandro Martinez
http://alejandromp.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

[Step Christopher via swift-evolution]

Looks good. Minor comments below:

> let t: P & C // Compiler error: subclass contraint must be in first position

Typo: contraint should be constraint
> ...
> typealias TA4 = D & P2
> typealias TA5 = E & P2
> 
> typealias TA5 = TA1 & TA2
> typealias TA5 = class & P1 & class & P2 // Expansion
> typealias TA5 = class & P1 & P2 // Normalization
> // TA5 is valid

The typealias 'T5' is repeated as both an initial composition, and as a 
demonstration of combining typealiases. 


> This proposal merges the concepts of class and AnyObject, which now have the 
> same meaning: they represent an existential for classes. They are four 
> solutions to this dilemna:
> Do nothing.
> Replace all uses of AnyObject by class, breaking source compatibility.
> Replace all uses of class by AnyObject, breaking source compatibility.
> Redefine AnyObject as typealias AnyObject = class.

I agree with other comments on recommending 4 here, and covering the others as 
alternatives. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino Heth via swift-evolution]

Great news — and I guess it's a plus that Discourse isn't PHP but Ruby, as I 
expect there are quite a lot Rubyists around here.
So, hopefully the issues that might exist (especially with the mail interface) 
can be addressed to make everyone happy.

Although Discourse looks like a really good fit, I would be interested to hear 
about other forum solutions as well: It would be a pity if we choose based on 
popularity only, ignoring alternatives completely just because they aren't that 
trendy.

- Tino

Anyone interested in starting to write a (possible) long-term solution using 
server-side Swift? Imho the challenge doesn't look that hard, and I've already 
been thinking about starting such a toy project to dive into the topic...
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Nil-rejection operator

[Jack Newcombe via swift-evolution]

This can actually be accomplished now using a closure:

let value = optionalValue ?? { throw CustomError.failure }()

However, this adds a layer of indirection that I’m not keen on and lacks the 
readability and maintainability of a well-defined operator.

The problem with changing the nil-coalescing operator is that it means allowing 
the second operand to be a statement rather than an expression, which I assume 
would be seen as an unacceptable.

> On 9 Feb 2017, at 07:56, Brent Royal-Gordon  wrote:
> 
>> On Feb 8, 2017, at 12:00 PM, Jack Newcombe via swift-evolution 
>>  wrote:
>> 
>> I propose the introduction of a nil-rejection operator (represented here as 
>> !!) as a complement to the above operators.
>> .
>> This operator should allow an equivalent behaviour to the forced unwrapping 
>> of a variable, but with the provision of an error to throw in place of 
>> throwing a fatal error.
>> 
>> - value !! Error :
>>  if value is nil, throw non-fatal error
>>  if value is not nil, return value
>> 
>> Example of how this syntax might work (Where CustomError: Error):
>> 
>>  let value = try optionalValue !! CustomError.failure
> 
> Rather than invent a new operator, I'd prefer to make `throw` an expression 
> rather than a statement. Then you could write:
> 
>   let value = optionalValue ?? throw CustomError.Failure
> 
> One issue here would be figuring out the proper return type for `throw`. 
> Although if `Never` were a subtype-of-all-types, that would of course work. 
> :^)
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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