Re: [swift-evolution] [Pitch] Percentage Type

[David Sweeris via swift-evolution]

Sent from my iPhone

> On Jan 16, 2018, at 23:45, Jonathan Hull via swift-evolution 
>  wrote:
> 
> Mainly semantics.
> 
> We could technically use Int instead of having a Bool type (just using 1 and 
> 0).  We don’t do that since Int and Bool have intrinsically different 
> meanings in code.  
> 
> What I am saying is that parameters that take the range 0 to 1 typically have 
> a fundamentally different meaning (or at least a different way of thinking 
> about them) than Doubles.  It would be nice to be able to see that 
> distinction when using APIs.
> 
> With both this and the Angle type, I am pointing out areas where, due to 
> historical reasons in C, we have conflated a bunch of types which have 
> different behavior, and then just expect programmers to be conscientious 
> enough to use them correctly in each case.  These types/numbers all have a 
> different forms of dimensionality.
> 
> I’d like to discuss that before we lock everything down.

+1 (although I think a “normalized to [0, 1]” type would be more useful than a 
“percentage” type)

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

Re: [swift-evolution] [pitch] adding toggle to Bool

[David Sweeris via swift-evolution]

> On Jan 11, 2018, at 22:15, Chris Eidhof via swift-evolution 
>  wrote:
> 
> Hey SE!
> 
> When we have a bunch of nested structs:
> 
> struct Sample {
> var bar: Bar
> }
> 
> struct Bar {
> var show: Bool
> }
> 
> var foo = Sample(bar: Bar(show: false))
> 
> It can be repetitive to toggle a deeply nested boolean:
> 
> foo.bar.show = !foo.bar.show // duplication
> 
> I sometimes add a `toggle` extension on `Bool`
> 
> extension Bool {
> mutating func toggle() {
> self = !self
> }
> }
> 
> This allows you to write the same code without duplication, and makes the 
> intent clearer:
> 
> foo.bar.show.toggle()
> 
> In other languages, I don't think the `toggle` would make as much sense, but 
> the mutable self makes this very useful.
> 
> After I posted it on Twitter, it turns out I'm not the only one: 
> https://twitter.com/PublicExtension/status/730434956376346624
> 
> I would have gone straight to a proposal, but I think we can do some 
> bikeshedding about the name of `toggle`?

“Toggle” works for me, if we go this route.

I have a question about the idea, though... Why limit this to Bools? In 
principle, as long as there aren’t any associated values involved, shouldn’t we 
be able to iterate through any exhaustive enum type? Bools are an obvious 
example of a case where “x.nextCase” is useful, but should we consider whether 
we ought to instead give this functionality to all enums that don’t have 
associated values?

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

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[David Sweeris via swift-evolution]

Sent from my iPhone

> On Nov 30, 2017, at 00:24, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
> 
>> On Nov 26, 2017, at 10:04 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> I’d like to formally propose the inclusion of user-defined dynamic member 
>> lookup types.
>> 
>> Here is my latest draft of the proposal:
>> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438
>> https://github.com/apple/swift-evolution/pull/768
>> 
>> An implementation of this design is available here:
>> https://github.com/apple/swift/pull/13076
>> 
>> The implementation is straight-forward and (IMO) non-invasive in the 
>> compiler.
> 
> 
> I think better interoperability with Python (and other OO languages in 
> widespread use) is a good goal, and I agree that the implementation of the 
> feature described is straight-forward and not terribly invasive in the 
> compiler.
> 
> However, I do not think this proposal is going in the right direction for 
> Swift. I have objections on several different grounds.
> 
> Philosophy
> Swift is, unabashedly, a strong statically-typed language. We don’t allow 
> implicit down casting, we require “as?” so you have to cope with the 
> possibility of failure (or use “as!” and think hard about the “!”). Even the 
> gaping hole that is AnyObject dispatch still requires the existence of an 
> @objc declaration and produces an optional lookup result, so the user must 
> contend with the potential for dynamic failure. Whenever we discuss adding 
> more dynamic features to Swift, there’s a strong focus on maintaining that 
> strong static type system.
> 
> IMO, this proposal is a significant departure from the fundamental character 
> of Swift, because it allows access to possibly-nonexistent members (as well 
> as calls with incorrect arguments, in the related proposal) without any 
> indication that the operation might fail. It’s easy to fall through these 
> cracks for any type that supports DynamicMemberLookupProtocol—a 
> single-character typo when using a DynamicMemberLookupProtocol-capable type 
> means you’ve fallen out of the safety that Swift provides. I think that’s a 
> poor experience for the Python interoperability case, but more on that in the 
> Tooling section below.
> 
> While we shouldn’t necessarily avoid a feature simply because it can be used 
> distastefully, consider something like this:
> 
>   public extension NSObject :  DynamicMemberLookupProtocol, 
> DynamicCallableProtocol { … }
> 
> that goes directly to the Objective-C runtime to resolve member lookups and 
> calls—avoiding @objc, bridging headers, and so on. It’s almost frighteningly 
> convenient, and one could imagine some mixed Objective-C/Swift code bases 
> where this would save a lot of typing (of code)… at the cost of losing static 
> typing in the language. The presence of that one extension means I can no 
> longer rely on the safety guarantees Swift normally provides, for any project 
> that imports that extension and uses a subclass of NSObject. At best, we as a 
> community decide “don’t do that”; at worse, some nontrivial fraction of the 
> community decides that the benefits outweigh the costs (for this type or some 
> other), and we can no longer say that Swift is a strong statically-typed 
> language without adding “unless you’re using something that adopts 
> DynamicMemberLookupProtocol”.
> 
> Tooling
> The Python interoperability enabled by this proposal *does* look fairly nice 
> when you look at a small, correctly-written example. However, absolutely none 
> of the tooling assistance we rely on when writing such code will work for 
> Python interoperability. Examples:
> 
> * As noted earlier, if you typo’d a name of a Python entity or passed the 
> wrong number of arguments to it, the compiler will not tell you: it’ll be a 
> runtime failure in the Python interpreter. I guess that’s what you’d get if 
> you were writing the code in Python, but Swift is supposed to be *better* 
> than Python if we’re to convince a community to use Swift instead.
> * Code completion won’t work, because Swift has no visibility into 
> declarations written in Python
> * Indexing/jump-to-definition/lookup documentation/generated interface won’t 
> ever work. None of the IDE features supported by SourceKit will work, which 
> will be a significant regression for users coming from a Python-capable IDE.
> 
> Statically-typed languages should be a boon for tooling, but if a user coming 
> from Python to Swift *because* it’s supposed to be a better development 
> experience actually sees a significantly worse development experience, we’re 
> not going to win them over. It’ll just feel inconsistent.
> 
> Dynamic Typing Features
> It’s possible that the right evolutionary path for Swift involves some notion 
> of dynamic typing, which would have a lot of the properties sought by this 
> proposal (and the DynamicCallableProtocol one). If 

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

[David Sweeris via swift-evolution]

> On Nov 25, 2017, at 08:05, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
>> On Sat, Nov 25, 2017 at 06:35 Mike Kluev  wrote:
>>> On 25 November 2017 at 03:12, Xiaodi Wu  wrote:
>> 
 On Fri, Nov 24, 2017 at 9:08 PM, Mike Kluev via swift-evolution 
  wrote:
>>> 
> On 24 November 2017 at 23:47, Douglas Gregor  wrote:
 
> 
> e.g., making all tuples of Equatable elements Equatable 
 
 that's already the case.. (all tuples of equatable elements are 
 equatable). no?
>>> 
>>> No, tuples do not conform to any protocols. There are hardcoded 
>>> implementations of `==` up to some arity in the stdlib to partially 
>>> mitigate the lack of protocol conformance.
>> 
>> to me as a user the end result is the same...
>> probably we need a better convincing example of what users may want that 
>> doesn't have a workaround now.
> 
> The workaround substantially bloats the standard library, and the result is 
> nothing close to the same because your type is still not Equatable. This 
> means that it cannot benefit from any generic algorithms. For example, an 
> array of such tuples cannot be Equatable in turn.
> 
>> speaking of ugliness, the ellipsis on the left of names is quite ugly:
>> 
>>  extension<...Elements : Equatable> (Elements...) : Equatable
> 
> Seems perfectly fine to me.

Agreed.

Speaking of which, have we started designing the syntax & semantics of the 
variadic generics/tuples system yet? I’ve been away from my computer a lot 
lately, and I tend to miss threads when subject lines gets truncated to 
“[swift-evolution][pitch] Some subj” on my phone.

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

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

[David Sweeris via swift-evolution]

> On Nov 21, 2017, at 22:54, Douglas Gregor via swift-evolution 
>  wrote:
> 
>> On Nov 21, 2017, at 10:48 PM, David Hart  wrote:
>> 
>> 
>> 
>> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>>> 
>>> 
 On Nov 21, 2017, at 10:37 PM, Chris Lattner  wrote:
 
 On Nov 21, 2017, at 9:25 PM, Douglas Gregor  wrote:
>> Or alternatively, one could decide to make the generics system *only and 
>> forever* work on nominal types, and make the syntactic sugar just be 
>> sugar for named types like Swift.Tuple, Function, and Optional.  Either 
>> design could work.
> 
> We don’t have a way to make it work for function types, though, because 
> of parameter-passing conventions. Well, assuming we don’t invent 
> something that allows:
> 
>   Function
> 
> to exist in the type system. Tuple labels have a similar problem.
 
 I’m totally aware of that and mentioned it upthread. 
>>> 
>>> Eh, sorry I missed it.
>>> 
  There are various encoding tricks that could make this work depending on 
 how you want to stretch the current generics system…
>>> 
>>> I think it’s straightforward and less ugly to make structural types allow 
>>> extensions and protocol conformances.
>> 
>> Can somebody explain to me what is less ugly about that? I would have 
>> naturally thought that the language would be simpler as a whole if there 
>> only existed nominal types and all structural types were just sugar over 
>> them.
> 
> See Thorsten’s response with, e.g.,
> 
> Function
> 
> which handles “inout” by adding wrappers around the parameter types (which 
> one would have to cope with in any user of Function), but still doesn’t 
> handle argument labels. To handle argument labels, we would need something 
> like strings as generic arguments.

Oh, good! A use case for “literals as generic parameters” other than Vectors 
and Fixed-Size Arrays!

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

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[David Sweeris via swift-evolution]

> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution 
>  wrote:
> 
> Hi Dave,
> 
> Thanks for bringing up this topic.  This has been kicked around a little, and 
> we’re still exploring different models on how to extend Swift.
> 
> The server APIs work group is one operational model for the community to 
> build out a new set of core libraries.  That work group was formed out of the 
> observation that there were different implementations of the same thing being 
> created by different Swift on server efforts, and that those different 
> efforts should pool those resources together and standardize on some 
> fundamentals.
> 
> That analogy could work here.  However, it also has possible major downsides. 
>  It can be heavyweight, and also artificially raise the importance of certain 
> people’s library efforts over others by creating a formal work group whose 
> efforts are expected to eventually be incorporated into the core Swift 
> distribution.  It would also force a discussion up front of what even makes 
> sense to incorporate into the core Swift distribution, which might be 
> artificially constraining the exploration of the set of libraries to 
> implement.
> 
> I need to think about your idea more, but my first reaction is that my 
> preferred route is that the community builds these libraries, ideally using 
> Swift Packages, and through trial and use we evaluate those libraries and 
> then decide if they should be incorporated as part of the core distribution.  
> There’s many factors involved in deciding if they can be incorporated into 
> the core distribution, but all of those could be informed by actually 
> building libraries and see them getting used.
> 
> We could also figure out a way to possibly highlight these efforts to the 
> Swift community, maybe on swift-evolution or other means — but all with the 
> expectation that these libraries are not *necessarily* going to be 
> standardized as part of the core swift distribution.  I don’t think that’s 
> all that bad either; not every library will make sense to incorporate into 
> the core Swift distribution (e.g., they are highly domain specific) but still 
> supporting their development would be beneficial to the community.
> 
> Note that any change going into the Swift core distribution inevitably 
> involves swift-evolution and the core team.  Changes going into the core 
> Swift distribution must meet a very high bar as far as implementation and 
> design, the confidence we have into committing to specific APIs (especially 
> since we’ll have ABI stability in Swift 5), and other factors.  Thus this 
> will not really alleviate much burden on the Core team or on the community — 
> one of the core goals of your proposal.  Further, incorporating all those 
> concerns up front when building libraries might be counterproductive.
> 
> FWIW, Ben Cohen and I have been talking about possibly using Swift packages 
> as a way to seed out experimental ideas for extensions to the Standard 
> Library.  This would allow ideas to be trialed by real usage (a complaint 
> I’ve seen about some changes we’ve made to Swift in the past).  Users could 
> build things on top of those libraries, knowing they are available as 
> packages, and if an API “graduates” to being part of the Standard Library the 
> user can then depend upon it being available there.  If it never graduates, 
> however, the package remains around.
> 
> One thing that resonates me in what you propose is about having a 
> “well-organized effort” whose aim is to make these libraries feel cohesive 
> and implemented well.  However, given that many of these naturally fall 
> somewhere in the spectrum of responsibilities within the Standard Library and 
> Foundation, I think it is self-misleading to think that the Core Team or 
> others would not be involved in these efforts if the intention is to possibly 
> incorporate these one day into the core Swift distribution.  There also may 
> be other ways to achieve that level of cohesion in API design, such as 
> through community discussion (possibly via the Swift.org  
> mailing lists/forums).  This discussion would not necessarily be the same as 
> the path to “ratification” of a library into core Swift, but a step that 
> could benefit many library authors (including considering ideas one day 
> incorporated into the core swift).  With such a mechanism many library 
> authors could benefit even if they do not intend to have the library as part 
> of the core distribution.
> 
> My apologies that these are all hand-wavy ideas, but I’m trying to paint a 
> possible alternative way to achieve your goal of more library evolution for 
> Swift without having such a formal work group that may be too heavy weight or 
> too narrowly focused.

FWIW, I don't think it much matters if they get rolled into the "core" Swift 
distribution or library... I think all that's really necessary (well, to the 

Re: [swift-evolution] “Integer” protocol?

[David Sweeris via swift-evolution]

> On Nov 1, 2017, at 14:54, Kelvin Ma via swift-evolution 
>  wrote:
> 
> 
> 
>> On Wed, Nov 1, 2017 at 12:15 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>>> On Wed, Nov 1, 2017 at 07:24 Daryle Walker  wrote:
>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
 On Oct 31, 2017, at 10:55 PM, Xiaodi Wu  wrote:
 
 Right, these issues were discussed when the proposal was introduced and 
 reviewed three times. In brief, what was once proposed as `Integer` was 
 renamed `BinaryInteger` to avoid confusion in name between `Integer` and 
 `Int`. It was also found to better reflect the semantics of the protocol, 
 as certain functions treated the value not merely as an integer but 
 operated specifically on its binary representation (for instance, the 
 bitwise operators).
 
 Do not confuse integers from their representation. Integers have no 
 intrinsic radix and all integers have a binary representation. This is 
 distinct from floating-point protocols, because many real values 
 representable exactly as a decimal floating-point value cannot be 
 represented exactly as a binary floating-point value.
>>> 
>>> Abstractly, integers have representations in nearly all real radixes. But 
>>> mandating base-2 properties for a numeric type that uses something else 
>>> (ternary, negadecimal, non-radix, etc.) in its storage is definitely 
>>> non-trivial. Hence the request for intermediate protocols that peel off the 
>>> binary requirements. 
>> 
>> Not only binary properties, but specifically two’s-complement binary 
>> properties. You are correct that some operations require thought for 
>> implementation if your type uses ternary storage, or for any type that does 
>> not specifically use two’s-complement representation internally, but having 
>> actually implemented them I can assure you it is not difficult to do 
>> correctly without even a CS degree.
>> 
>> Again, one must distinguish between the actual representation in storage and 
>> semantics, which is what Swift protocols guarantee. The protocols are 
>> totally agnostic to the internal storage representation. The trade-off for 
>> supporting ternary _semantics_ is an additional set of protocols which 
>> complicates understanding and use in generic algorithms. I am not aware of 
>> tritwise operations being sufficiently in demand.
> 
> Before everyone gets carried away with these protocols, can I ask what the 
> real use case for ternary integers is? Also I’m not a fan of bikeshedding 
> protocols for things that don’t exist (yet).

I can’t imagine it’d ever get far enough for me to care about Swift’s stance on 
the issue, but I want to build a 9-“trit” breadboard computer some day, just 
for my own edification/amusement.

(FWIW, while I’m not 100% on how the integer protocols ended up, this isn’t the 
part that I’d change)

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

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

[David Sweeris via swift-evolution]

> On Oct 25, 2017, at 4:41 AM, David Hart via swift-evolution 
>  wrote:
> 
> I got bit again by a sneaky memory leak concerning local functions and would 
> like to discuss a small language change. I vaguely remember this being 
> discussed in the past, but can’t find the thread (if anybody could point me 
> to it, I’d appreciate it). Basically, here’s an example of the leak:
> 
> class A {
> func foo() {
> func local() {
> bar()
> }
> 
> methodWithEscapingClosure { [unowned self] _ in
> self.bar()
> local() // this leaks because local captures self
> }
> }
> 
> func bar() {
> }
> }
> 
> Its sneaky because local’s capturing of self is not obvious if you’ve trained 
> your brain to watch out for calls prefixed with self. I would suggest having 
> the compiler force users to make self capturing explicit, the same way it 
> does for closures:
> 
> class A {
> func foo() {
> func local() {
> bar() // error: Call to method ‘bar' in function ‘local' requires 
> explicit 'self.' to make capture semantics explicit
> }
> 
>   // ...
> }
> }
> 
> What do you think?

Works for me

- Dave Sweeris

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

Re: [swift-evolution] [draft] Target environment platform condition

[David Sweeris via swift-evolution]

One quick question... WRT `os()`, should that take a string instead of some 
keywordish thing? There's at least one OS which has a Swift port, but doesn't 
show up on that list (Haiku: 
https://www.haiku-os.org/blog/return0e/2017-08-28_gsoc_2017_porting_swift_to_haiku_-_final_report/
 
)

- Dave Sweeris

> On Oct 24, 2017, at 8:05 PM, Graydon Hoare via swift-evolution 
>  wrote:
> 
> Hi,
> 
> I'd like to propose a variant of a very minor, additive proposal Erica Sadun 
> posted last year, that cleans up a slightly messy idiomatic use of 
> conditional compilation in libraries. The effects should be quite limited; 
> I'd call it a "standard library" addition except that the repertoire of 
> compiler-control statements isn't strictly part of the stdlib.
> 
> Proposal is here: 
> https://gist.github.com/graydon/809af2c726cb1a27af64435e47ef4e5d 
> 
> 
> Implementation (minus fixits) is here: 
> https://github.com/graydon/swift/commit/16493703ea297a1992ccd0fc4d2bcac7d078c982
>  
> 
> 
> Feedback appreciated,
> 
> -Graydon
> 
> ___
> 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] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[David Sweeris via swift-evolution]

> On Oct 20, 2017, at 22:18, Eagle Offshore <eagleoffsh...@mac.com> wrote:
> 
> 
>> On Oct 20, 2017, at 2:55 PM, David Sweeris via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> how else are we supposed to express nuances when the language’s default is 
>> wrong for the code in question?
> 
> Fix the defaults?

K, then how do you express nuances where the “fixed” defaults are wrong?

> Honestly, I'm not sure how I've been programming for so long (30+ years) 
> without having to add half a dozen annotations to every single declaration.

Different languages offer different levels of “compiler smarts”, and have 
different mechanisms for exposing said “smarts”. What language(s) are you used 
to?

> "If you think C++ is not overly complicated, just what is a protected 
> abstract virtual base pure virtual private destructor and when was the last 
> time you needed one? 
> — Tom Cargill"
> 
> 
> Same applies to Swift at this point.  Its jumped the shark on annotations.

I think @discardableResult is the only one that’s generally used much in 
non-library code... There’s an annotation to specify the inlining behavior for 
when you don’t want the compiler making that decision, and one for something 
about transparency in the stdlib (I don’t think it’s part of the “public” 
language, though, because it starts with a “_”). I wouldn’t be too surprised if 
I’ve missed something, but AFAIK, Swift currently only has those two or three.

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

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[David Sweeris via swift-evolution]

> On Oct 20, 2017, at 10:54, Eagle Offshore via swift-evolution 
>  wrote:
> 
> +1
> 
> I really feel like the number of modifiers and decorators and annotations 
> etchas reached the point of illegibility.
> 
> It purpose="intensifier">reallyridiculous
> 
> That's what trying to read swift is getting to be like.
> 
> Trying to make every single nuance explicit is a fool's errand and is killing 
> readability.

Agree that annotations can get unwieldy, but how else are we supposed to 
express nuances when the language’s default is wrong for the code in question?

> Also, the choice to discard a result is properly the provenance of the 
> caller, not an intrinsic feature of a function.

Was that position argued during the proposal review? I don’t remember... In any 
case, I think the “very high bar” we have now for breaking source compatibility 
makes it unlikely to change at this point (OTOH, I’m frequently wrong here)

> I'll stop now.

Feel free to voice your concerns... Obviously I can’t promise anyone will agree 
or anything, but if you think you have a point that hasn’t already been 
discussed, we want to hear it! (Or at least I do... I’m just a random dude on 
the internet and don’t “speak for the list” or anything, but that’s been the 
general attitude as long as I’ve been hanging out here)

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

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

[David Sweeris via swift-evolution]

Oh, this is weird... I replied to a different thread an hour ago. Somehow that 
message hasn't posted yet, but this one from three days ago apparently got 
reposted? Weird.
> On Oct 19, 2017, at 12:11 PM, David Sweeris via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
> On Oct 16, 2017, at 10:42, BJ Homer via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>>> On Oct 16, 2017, at 8:20 AM, Thorsten Seitz via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>>> Am 16.10.2017 um 07:19 schrieb Xiaodi Wu <xiaodi...@gmail.com 
>>>> <mailto:xiaodi...@gmail.com>>:
>>> 
>>>> What useful generic algorithms would this protocol support that are not 
>>>> already possible?
>>> 
>>> It would allow expressing generic algorithms depending on an order.
>>> 
>>> -Thorsten
>> 
>> We can already express generic algorithms that depend on an order—any 
>> generic algorithm that works on a Sequence works on something that is 
>> ordered. A Swift Set has an undefined order right now, but a generic 
>> algorithm working on any arbitrary Sequence likely doesn’t care about what 
>> the order, just that an order exists. And a Swift Set does indeed have an 
>> order. If you have a generic algorithm that only works on inputs sorted in a 
>> particular manner, then you’ve likely either documented that or added a 
>> “sortedBy” parameter. Otherwise, you probably just want to be able to 
>> iterate through everything.
>> 
>> Let’s assume, though, that you wanted to write an algorithm that works only 
>> on MeaningfullyOrdered inputs. 
>> 
>> func extractInfo(_ input: T) { }
>> extractInfo(someArray)
>> 
>> What stops the caller from simply wrapping the Set in an Array?
>> 
>> extractInfo(Array(someSet))
>> 
>> The Array constructed here is going to reflect the arbitrary ordering 
>> provided by Set, but as far as the type system is concerned, the input is an 
>> Array, which is certainly meaningfully-ordered. Have we gained anything by 
>> requiring the caller to wrap the input in an array? We’ve made the call site 
>> a bit more awkward, and we’ve lost a bit of performance. We certainly need 
>> to be able to convert Sets in to Arrays; to eliminate that would be 
>> massively source-breaking, and it’s not clear that allowing that conversion 
>> is actively harmful, so it’s unlikely to change in Swift 5.
> 
> Should/could we just rename `Set` to `UniquedArray` or something like that? 
> This is starting to feel a bit like the access control debate.
> 
> - Dave Sweeris
> ___
> 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] [Draft] Rename Sequence.elementsEqual

[David Sweeris via swift-evolution]

> On Oct 16, 2017, at 10:42, BJ Homer via swift-evolution 
>  wrote:
> 
>>> On Oct 16, 2017, at 8:20 AM, Thorsten Seitz via swift-evolution 
>>>  wrote:
>>> 
>>> Am 16.10.2017 um 07:19 schrieb Xiaodi Wu :
>> 
>>> What useful generic algorithms would this protocol support that are not 
>>> already possible?
>> 
>> It would allow expressing generic algorithms depending on an order.
>> 
>> -Thorsten
> 
> We can already express generic algorithms that depend on an order—any generic 
> algorithm that works on a Sequence works on something that is ordered. A 
> Swift Set has an undefined order right now, but a generic algorithm working 
> on any arbitrary Sequence likely doesn’t care about what the order, just that 
> an order exists. And a Swift Set does indeed have an order. If you have a 
> generic algorithm that only works on inputs sorted in a particular manner, 
> then you’ve likely either documented that or added a “sortedBy” parameter. 
> Otherwise, you probably just want to be able to iterate through everything.
> 
> Let’s assume, though, that you wanted to write an algorithm that works only 
> on MeaningfullyOrdered inputs. 
> 
> func extractInfo(_ input: T) { }
> extractInfo(someArray)
> 
> What stops the caller from simply wrapping the Set in an Array?
> 
> extractInfo(Array(someSet))
> 
> The Array constructed here is going to reflect the arbitrary ordering 
> provided by Set, but as far as the type system is concerned, the input is an 
> Array, which is certainly meaningfully-ordered. Have we gained anything by 
> requiring the caller to wrap the input in an array? We’ve made the call site 
> a bit more awkward, and we’ve lost a bit of performance. We certainly need to 
> be able to convert Sets in to Arrays; to eliminate that would be massively 
> source-breaking, and it’s not clear that allowing that conversion is actively 
> harmful, so it’s unlikely to change in Swift 5.

Should/could we just rename `Set` to `UniquedArray` or something like that? 
This is starting to feel a bit like the access control debate.

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

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

[David Sweeris via swift-evolution]

> On Oct 18, 2017, at 1:04 PM, Adam Kemp via swift-evolution 
>  wrote:
> 
> 
>> On Oct 18, 2017, at 12:25 PM, Thorsten Seitz via swift-evolution 
>>  wrote:
>> 
>> Therefore having `elementsEqual` as API for unordered collections is a 
>> source of bugs …
> 
> You keep saying that, and yet after repeated requests to provide evidence you 
> still have not backed up this claim. How many bugs are caused by this? 
> Hypotheticals are not evidence. Show us how much of a problem this is in the 
> real world. Why do you think this is so important to fix? What impact is it 
> going to have? If it weren’t for this thread would you even know the problem 
> existed?

How many bugs have been caused by floating point types violating the 
programmer's mental model of how numbers work? To me, their both in the same 
category... both involve specific types that claim to adhere to a certain 
behavior, and both don't in sometimes subtle ways.

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

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

[David Sweeris via swift-evolution]

> On Oct 17, 2017, at 9:34 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
> On Tue, Oct 17, 2017 at 09:42 Jonathan Hull  > wrote:
>> On Oct 17, 2017, at 5:44 AM, Xiaodi Wu > > wrote:
>> 
>> 
>> On Tue, Oct 17, 2017 at 00:56 Thorsten Seitz > > wrote:
>> 
>> 
>> Am 17.10.2017 um 00:13 schrieb Xiaodi Wu > >:
>> 
>>> 
>>> On Mon, Oct 16, 2017 at 14:21 Thorsten Seitz >> > wrote:
 Am 16.10.2017 um 16:20 schrieb Xiaodi Wu via swift-evolution 
 >:
 
 
 On Mon, Oct 16, 2017 at 05:48 Jonathan Hull > wrote:
 
> On Oct 15, 2017, at 9:58 PM, Xiaodi Wu  > wrote:
> 
> On Sun, Oct 15, 2017 at 8:51 PM, Jonathan Hull  > wrote:
> 
>> On Oct 14, 2017, at 10:48 PM, Xiaodi Wu > > wrote:
  That ordering can be arbitrary, but it shouldn’t leak internal 
 representation such that the method used to create identical things 
 affects the outcome of generic methods because of differences in 
 internal representation.
 
 
>  It would be better to say that the iteration order is well-defined. 
> That will almost always mean documented, and usually predictable 
> though obviously e.g. RNGs and iterating in random order will not be 
> predictable by design.
> 
>> That's actually more semantically constrained than what Swift calls 
>> a `Collection` (which requires conforming types to be multi-pass 
>> and(?) finite). By contrast, Swift's `SpongeBob` protocol explicitly 
>> permits conforming single-pass, infinite, and/or unordered types. 
> 
> I think you’re talking about Sequence here, I’ve lost track of your 
> nonsense by now. Yes, the current Swift protocol named Sequence 
> allows unordered types. You seem to keep asserting that but not 
> actually addressing my argument, which is that allowing Sequences to 
> be unordered with the current API is undesired and actively harmful, 
> and should therefore be changed.
> 
> What is harmful about it?
 
 After thinking about it, I think the harmful bit is that unordered 
 sequences are leaking internal representation (In your example, this 
 is causing people to be surprised when two sets with identical 
 elements are generating different sequences/orderings based on how 
 they were created).  You are correct when you say that this problem is 
 even true for for-in.
 
 I would not say it is a problem. Rather, by definition, iteration 
 involves retrieving one element after another; if you're allowed to do 
 that with Set, then the elements of a Set are observably ordered in 
 some way. Since it's not an OrderedSet--i.e., order doesn't 
 matter--then the only sensible conclusion is that the order of 
 elements obtained in a for...in loop must be arbitrary. If you think 
 this is harmful, then you must believe that one should be prohibited 
 from iterating over an instance of Set. Otherwise, Set is inescapably 
 a Sequence by the Swift definition of Sequence. All extension methods 
 on Sequence like drop(while:) are really just conveniences for common 
 things that you can do with iterated access; to my mind, they're 
 essentially just alternative ways of spelling various for...in loops.
>>> 
>>> I think an argument could be made that you shouldn’t be able to iterate 
>>> over a set without first defining an ordering on it (even if that 
>>> ordering is somewhat arbitrary).  Maybe we have something like a 
>>> “Sequenc(e)able” protocol which defines things which can be turned into 
>>> a sequence when combined with some sort of ordering.  One possible 
>>> ordering could be the internal representation (At least in that case we 
>>> are calling it out specifically).  If I had to say 
>>> “setA.arbitraryOrder.elementsEqual(setB.arbitraryOrder)” I would 
>>> definitely be less surprised when it returns false even though setA == 
>>> setB.
>>> 
>>> Well, that's a totally different direction, then; you're arguing that 
>>> `Set` and `Dictionary` should not conform to `Sequence` altogether. 
>>> That's fine (it's also a direction that some of us explored off-list a 
>>> while ago), but at this point in Swift's 

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

[David Sweeris via swift-evolution]

> On Oct 16, 2017, at 1:07 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> 
> On Mon, Oct 16, 2017 at 13:15 David Sweeris <daveswee...@mac.com 
> <mailto:daveswee...@mac.com>> wrote:
> 
> On Oct 16, 2017, at 09:21, Michael Ilseman <milse...@apple.com 
> <mailto:milse...@apple.com>> wrote:
> 
>> 
>> 
>>> On Oct 16, 2017, at 8:46 AM, David Sweeris via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
>>> On Oct 16, 2017, at 07:20, Xiaodi Wu via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>>> 
>>>> On Mon, Oct 16, 2017 at 05:48 Jonathan Hull <jh...@gbis.com 
>>>> <mailto:jh...@gbis.com>> wrote:
>>>> 
>>>>> On Oct 15, 2017, at 9:58 PM, Xiaodi Wu <xiaodi...@gmail.com 
>>>>> <mailto:xiaodi...@gmail.com>> wrote:
>>>>> 
>>>>> On Sun, Oct 15, 2017 at 8:51 PM, Jonathan Hull <jh...@gbis.com 
>>>>> <mailto:jh...@gbis.com>> wrote:
>>>>> 
>>>>>> On Oct 14, 2017, at 10:48 PM, Xiaodi Wu <xiaodi...@gmail.com 
>>>>>> <mailto:xiaodi...@gmail.com>> wrote:
>>>>>>>>  That ordering can be arbitrary, but it shouldn’t leak internal 
>>>>>>>> representation such that the method used to create identical things 
>>>>>>>> affects the outcome of generic methods because of differences in 
>>>>>>>> internal representation.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>>  It would be better to say that the iteration order is well-defined. 
>>>>>>>>> That will almost always mean documented, and usually predictable 
>>>>>>>>> though obviously e.g. RNGs and iterating in random order will not be 
>>>>>>>>> predictable by design.
>>>>>>>>> 
>>>>>>>>>> That's actually more semantically constrained than what Swift calls 
>>>>>>>>>> a `Collection` (which requires conforming types to be multi-pass 
>>>>>>>>>> and(?) finite). By contrast, Swift's `SpongeBob` protocol explicitly 
>>>>>>>>>> permits conforming single-pass, infinite, and/or unordered types. 
>>>>>>>>> 
>>>>>>>>> I think you’re talking about Sequence here, I’ve lost track of your 
>>>>>>>>> nonsense by now. Yes, the current Swift protocol named Sequence 
>>>>>>>>> allows unordered types. You seem to keep asserting that but not 
>>>>>>>>> actually addressing my argument, which is that allowing Sequences to 
>>>>>>>>> be unordered with the current API is undesired and actively harmful, 
>>>>>>>>> and should therefore be changed.
>>>>>>>>> 
>>>>>>>>> What is harmful about it?
>>>>>>>> 
>>>>>>>> After thinking about it, I think the harmful bit is that unordered 
>>>>>>>> sequences are leaking internal representation (In your example, this 
>>>>>>>> is causing people to be surprised when two sets with identical 
>>>>>>>> elements are generating different sequences/orderings based on how 
>>>>>>>> they were created).  You are correct when you say that this problem is 
>>>>>>>> even true for for-in.
>>>>>>>> 
>>>>>>>> I would not say it is a problem. Rather, by definition, iteration 
>>>>>>>> involves retrieving one element after another; if you're allowed to do 
>>>>>>>> that with Set, then the elements of a Set are observably ordered in 
>>>>>>>> some way. Since it's not an OrderedSet--i.e., order doesn't 
>>>>>>>> matter--then the only sensible conclusion is that the order of 
>>>>>>>> elements obtained in a for...in loop must be arbitrary. If you think 
>>>>>>>> this is harmful, then you must believe that one should be prohibited 
>>>>>>>> from iterating over an instance of Set. Otherwise, Set is inescapably 
>>>>>>>> a Sequence by the Swift definition of Sequence. All extension methods 
>>&

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

[David Sweeris via swift-evolution]

> On Oct 16, 2017, at 10:42, BJ Homer via swift-evolution 
>  wrote:
> 
>>> On Oct 16, 2017, at 8:20 AM, Thorsten Seitz via swift-evolution 
>>>  wrote:
>>> 
>>> Am 16.10.2017 um 07:19 schrieb Xiaodi Wu :
>> 
>>> What useful generic algorithms would this protocol support that are not 
>>> already possible?
>> 
>> It would allow expressing generic algorithms depending on an order.
>> 
>> -Thorsten
> 
> We can already express generic algorithms that depend on an order—any generic 
> algorithm that works on a Sequence works on something that is ordered. A 
> Swift Set has an undefined order right now, but a generic algorithm working 
> on any arbitrary Sequence likely doesn’t care about what the order, just that 
> an order exists. And a Swift Set does indeed have an order. If you have a 
> generic algorithm that only works on inputs sorted in a particular manner, 
> then you’ve likely either documented that or added a “sortedBy” parameter. 
> Otherwise, you probably just want to be able to iterate through everything.
> 
> Let’s assume, though, that you wanted to write an algorithm that works only 
> on MeaningfullyOrdered inputs. 
> 
> func extractInfo(_ input: T) { }
> extractInfo(someArray)
> 
> What stops the caller from simply wrapping the Set in an Array?
> 
> extractInfo(Array(someSet))
> 
> The Array constructed here is going to reflect the arbitrary ordering 
> provided by Set, but as far as the type system is concerned, the input is an 
> Array, which is certainly meaningfully-ordered. Have we gained anything by 
> requiring the caller to wrap the input in an array? We’ve made the call site 
> a bit more awkward, and we’ve lost a bit of performance. We certainly need to 
> be able to convert Sets in to Arrays; to eliminate that would be massively 
> source-breaking, and it’s not clear that allowing that conversion is actively 
> harmful, so it’s unlikely to change in Swift 5.

Should/could we just rename `Set` to `UniquedArray` or something like that? 
This is starting to feel a bit like the access control debate.

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

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

[David Sweeris via swift-evolution]

> On Oct 16, 2017, at 09:21, Michael Ilseman <milse...@apple.com> wrote:
> 
> 
> 
>> On Oct 16, 2017, at 8:46 AM, David Sweeris via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> 
>> On Oct 16, 2017, at 07:20, Xiaodi Wu via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>>> 
>>>> On Mon, Oct 16, 2017 at 05:48 Jonathan Hull <jh...@gbis.com> wrote:
>>>> 
>>>>> On Oct 15, 2017, at 9:58 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>>>> 
>>>>>> On Sun, Oct 15, 2017 at 8:51 PM, Jonathan Hull <jh...@gbis.com> wrote:
>>>>>> 
>>>>>>>> On Oct 14, 2017, at 10:48 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>>>>>>>>>>  That ordering can be arbitrary, but it shouldn’t leak internal 
>>>>>>>>>>> representation such that the method used to create identical things 
>>>>>>>>>>> affects the outcome of generic methods because of differences in 
>>>>>>>>>>> internal representation.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>>  It would be better to say that the iteration order is 
>>>>>>>>>>>>> well-defined. That will almost always mean documented, and 
>>>>>>>>>>>>> usually predictable though obviously e.g. RNGs and iterating in 
>>>>>>>>>>>>> random order will not be predictable by design.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> That's actually more semantically constrained than what Swift 
>>>>>>>>>>>>>>> calls a `Collection` (which requires conforming types to be 
>>>>>>>>>>>>>>> multi-pass and(?) finite). By contrast, Swift's `SpongeBob` 
>>>>>>>>>>>>>>> protocol explicitly permits conforming single-pass, infinite, 
>>>>>>>>>>>>>>> and/or unordered types. 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I think you’re talking about Sequence here, I’ve lost track of 
>>>>>>>>>>>>>> your nonsense by now. Yes, the current Swift protocol named 
>>>>>>>>>>>>>> Sequence allows unordered types. You seem to keep asserting that 
>>>>>>>>>>>>>> but not actually addressing my argument, which is that allowing 
>>>>>>>>>>>>>> Sequences to be unordered with the current API is undesired and 
>>>>>>>>>>>>>> actively harmful, and should therefore be changed.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> What is harmful about it?
>>>>>>>>>>>> 
>>>>>>>>>>>> After thinking about it, I think the harmful bit is that unordered 
>>>>>>>>>>>> sequences are leaking internal representation (In your example, 
>>>>>>>>>>>> this is causing people to be surprised when two sets with 
>>>>>>>>>>>> identical elements are generating different sequences/orderings 
>>>>>>>>>>>> based on how they were created).  You are correct when you say 
>>>>>>>>>>>> that this problem is even true for for-in.
>>>>>>>>>>> 
>>>>>>>>>>> I would not say it is a problem. Rather, by definition, iteration 
>>>>>>>>>>> involves retrieving one element after another; if you're allowed to 
>>>>>>>>>>> do that with Set, then the elements of a Set are observably ordered 
>>>>>>>>>>> in some way. Since it's not an OrderedSet--i.e., order doesn't 
>>>>>>>>>>> matter--then the only sensible conclusion is that the order of 
>>>>>>>>>>> elements obtained in a for...in loop must be arbitrary. If you 
>>>>>>>>>>> think this is harmful, then you must believe that one should be 
>>>>>>>>>>> prohibited from iterating over an instance of Set. Otherwise, Set 
>>>&g

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

[David Sweeris via swift-evolution]

> On Oct 16, 2017, at 07:20, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
>> On Mon, Oct 16, 2017 at 05:48 Jonathan Hull  wrote:
>> 
>>> On Oct 15, 2017, at 9:58 PM, Xiaodi Wu  wrote:
>>> 
 On Sun, Oct 15, 2017 at 8:51 PM, Jonathan Hull  wrote:
 
>> On Oct 14, 2017, at 10:48 PM, Xiaodi Wu  wrote:
>  That ordering can be arbitrary, but it shouldn’t leak internal 
> representation such that the method used to create identical things 
> affects the outcome of generic methods because of differences in 
> internal representation.
>> 
>> 
>>>  It would be better to say that the iteration order is 
>>> well-defined. That will almost always mean documented, and usually 
>>> predictable though obviously e.g. RNGs and iterating in random 
>>> order will not be predictable by design.
 
> That's actually more semantically constrained than what Swift 
> calls a `Collection` (which requires conforming types to be 
> multi-pass and(?) finite). By contrast, Swift's `SpongeBob` 
> protocol explicitly permits conforming single-pass, infinite, 
> and/or unordered types. 
 
 I think you’re talking about Sequence here, I’ve lost track of 
 your nonsense by now. Yes, the current Swift protocol named 
 Sequence allows unordered types. You seem to keep asserting that 
 but not actually addressing my argument, which is that allowing 
 Sequences to be unordered with the current API is undesired and 
 actively harmful, and should therefore be changed.
>>> 
>>> What is harmful about it?
>> 
>> After thinking about it, I think the harmful bit is that unordered 
>> sequences are leaking internal representation (In your example, this 
>> is causing people to be surprised when two sets with identical 
>> elements are generating different sequences/orderings based on how 
>> they were created).  You are correct when you say that this problem 
>> is even true for for-in.
> 
> I would not say it is a problem. Rather, by definition, iteration 
> involves retrieving one element after another; if you're allowed to 
> do that with Set, then the elements of a Set are observably ordered 
> in some way. Since it's not an OrderedSet--i.e., order doesn't 
> matter--then the only sensible conclusion is that the order of 
> elements obtained in a for...in loop must be arbitrary. If you think 
> this is harmful, then you must believe that one should be prohibited 
> from iterating over an instance of Set. Otherwise, Set is inescapably 
> a Sequence by the Swift definition of Sequence. All extension methods 
> on Sequence like drop(while:) are really just conveniences for common 
> things that you can do with iterated access; to my mind, they're 
> essentially just alternative ways of spelling various for...in loops.
 
 I think an argument could be made that you shouldn’t be able to 
 iterate over a set without first defining an ordering on it (even if 
 that ordering is somewhat arbitrary).  Maybe we have something like a 
 “Sequenc(e)able” protocol which defines things which can be turned 
 into a sequence when combined with some sort of ordering.  One 
 possible ordering could be the internal representation (At least in 
 that case we are calling it out specifically).  If I had to say 
 “setA.arbitraryOrder.elementsEqual(setB.arbitraryOrder)” I would 
 definitely be less surprised when it returns false even though setA == 
 setB.
>>> 
>>> Well, that's a totally different direction, then; you're arguing that 
>>> `Set` and `Dictionary` should not conform to `Sequence` altogether. 
>>> That's fine (it's also a direction that some of us explored off-list a 
>>> while ago), but at this point in Swift's evolution, realistically, it's 
>>> not within the realm of possible changes.
>> 
>> I am actually suggesting something slightly different.  Basically, Set 
>> and Dictionary’s conformance to Collection would have a different 
>> implementation.  They would conform to another protocol declaring that 
>> they are unordered. That protocol would fill in part of the conformance 
>> to sequence/collection using a default ordering, which is mostly 
>> arbitrary, but guaranteed to produce the same ordering for the same list 
>> of elements (even across collection types).  This would be safer, but a 
>> tiny bit slower than what we have now (We could also potentially develop 
>> a way for 

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[David Sweeris via swift-evolution]

> On Oct 9, 2017, at 9:02 AM, Dave DeLong via swift-evolution 
>  wrote:
> 
> Oooo, I really like this.
> 
> It also brings up an interesting point on the whole async discussion. Doesn’t 
> the async apply to the return value and not the other stuff?

No, the whole function including any side effects gets executed asynchronously. 
"Pure" functions could (sorta) be regarded as only having the "async" apply to 
the return value, but that mental model is incorrect and it only gives the 
right "answer" as a consequence of the function being pure.

At least, if I understand things correctly.

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

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

[David Sweeris via swift-evolution]

On Oct 3, 2017, at 21:47, Chris Lattner <clatt...@nondot.org 
<mailto:clatt...@nondot.org>> wrote:

> 
>> On Oct 3, 2017, at 4:05 PM, David Sweeris <daveswee...@mac.com 
>> <mailto:daveswee...@mac.com>> wrote:
>> 
>> 
>>> On Oct 2, 2017, at 10:06 PM, Chris Lattner <clatt...@nondot.org 
>>> <mailto:clatt...@nondot.org>> wrote:
>>> 
>>> On Oct 2, 2017, at 9:12 PM, David Sweeris via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>> Keep in mind that Swift already goes far above and beyond in terms of 
>>>>> operators
>>>> Yep, that's is a large part of why I'm such a Swift fan :-D
>>> 
>>> Fortunately, no one is seriously proposing a major curtailing of the 
>>> capabilities here, we’re just trying to rationalize the operator set, which 
>>> is a bit of a mess at present.
>> I guess I don't really understand why it's currently "a bit of a mess”.
> 
> Read the motivation/inconsistency section of:
> https://github.com/xwu/swift-evolution/blob/7c2c4df63b1d92a1677461f41bc638f31926c9c3/proposals/-refining-identifier-and-operator-symbology.md
>  
> <https://github.com/xwu/swift-evolution/blob/7c2c4df63b1d92a1677461f41bc638f31926c9c3/proposals/-refining-identifier-and-operator-symbology.md>
> 
>>> Set algebra is an illustrative example, because it is both used by people 
>>> who are experts and people who are not.  As far as policies go, I think it 
>>> makes sense for Swift libraries to define operator-like things as named 
>>> functions (e.g. “intersection") and also define operators (“∩”) which can 
>>> optionally be used in source bases that want them for convenience.  The 
>>> compiler and language cannot know whether a code base is written and 
>>> maintained by experts who know the symbols and who value their clarity 
>>> (over the difficulty typing and recognizing them), and this approach allows 
>>> maintainers of the codebase to pick their own policies.
>> Oh, yeah, I can't imagine a situation in which I'd think it'd be a good idea 
>> to not define a named function to go along with a unicode operator. I'm 
>> mainly concerned that we not limit the people in 5) unless we need to. And 
>> to be clear, if we actually need to, then I'm fine with doing that... It's 
>> just that -- like I said earlier in this message -- I don't clearly 
>> understand why this is a problem.
> 
> Sure, that’s fair.  This is an issue we’ve been tracking since the Swift 2.x 
> (!) days, so there is a lot of context that is probably not immediately 
> obvious if you haven’t been following it since then.  The proposal link above 
> talks about the damage that we still carry.

Oh! I didn't realize the proposal had already been written! Yeah, that clears 
things up quite a bit, thanks for posting it :-)

Xiaodi Wu, I’m sorry I ever doubted you :-)

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

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

[David Sweeris via swift-evolution]

> On Oct 2, 2017, at 10:06 PM, Chris Lattner <clatt...@nondot.org> wrote:
> 
> On Oct 2, 2017, at 9:12 PM, David Sweeris via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> Keep in mind that Swift already goes far above and beyond in terms of 
>>> operators
>> Yep, that's is a large part of why I'm such a Swift fan :-D
> 
> Fortunately, no one is seriously proposing a major curtailing of the 
> capabilities here, we’re just trying to rationalize the operator set, which 
> is a bit of a mess at present.
I guess I don't really understand why it's currently "a bit of a mess". Maybe I 
should go take a look at the relevant compiler code to try to get a better 
understanding of what you're talking about. Or is this purely a matter of 
finding places where we disagree with Unicode's character classification? If 
so, I think I'm back at not quite getting it... In any case, I've apparently 
misunderstood something because I was under the impression that this would lead 
to a "major curtailing".

>>> in that: (a) it allows overloading of almost all standard operators; (b) it 
>>> permits the definition of effectively an infinite number of custom 
>>> operators using characters found in standard operators; (c) it permits the 
>>> definition of custom precedences for custom operators; and (d) it 
>>> additionally permits the use of a wide number of Unicode characters for 
>>> custom operators. Most systems programming languages don't even allow (a), 
>>> let alone (b) or (c). Even dramatically curtailing (d) leaves Swift with an 
>>> unusually expansive support for custom operators.
> 
>> Yes, but many of those custom operators won't have a clear meaning because 
>> operators are rarely limited to pre-existing symbols like "" (which 
>> doesn't mean anything at all AFAIK), so operators that are widely known 
>> within some field probably won't be widely known to the general public, 
>> which, IIUC, seems to be your standard for inclusion(?). Please let me know 
>> if that's not your position... I hate being misunderstood probably more than 
>> the next person, and I wouldn't want to be guilty of that myself.
> 
> The approach to operator handling in Swift is very intentional.  IMO, it is 
> well known that:
> 
> 1) Operators can make code significantly easier to understand by reducing 
> noise from complex expressions: writing x.matmul(y) is insane 
> <https://www.python.org/dev/peps/pep-0465/> if you’re doing a lot of matrix 
> multiplies.
> 2) Operators can be completely opaque to someone who doesn’t know them, and 
> sometimes named functions are more clear.
> 3) Named functions can also sometimes be completely opaque if you don't know 
> them, e.g. "let x = cholesky(y)"
> 4) Languages with fixed operator sets that also allow overloading (e.g. C++) 
> end up with those operators being abused.
> 5) Some code can only be written and maintained by domain experts, and those 
> experts often know the operators.
> 
> Swift’s approach is basically to say to users: “ok we allow overloaded 
> operators, but at least if you encounter some operation that you don’t know… 
> you know that you don’t know it”.  If you encounter "if ¬x {“  or “a ∩ b” in 
> some source code, at least you can command click, jump to the definition and 
> read what it does: you aren’t misled into thinking that the expression is 
> some familiar thing, but find out later it was overloaded to do something 
> crazy (bitshifts for i/o?  really??? :).
> 
> Set algebra is an illustrative example, because it is both used by people who 
> are experts and people who are not.  As far as policies go, I think it makes 
> sense for Swift libraries to define operator-like things as named functions 
> (e.g. “intersection") and also define operators (“∩”) which can optionally be 
> used in source bases that want them for convenience.  The compiler and 
> language cannot know whether a code base is written and maintained by experts 
> who know the symbols and who value their clarity (over the difficulty typing 
> and recognizing them), and this approach allows maintainers of the codebase 
> to pick their own policies.
Oh, yeah, I can't imagine a situation in which I'd think it'd be a good idea to 
not define a named function to go along with a unicode operator. I'm mainly 
concerned that we not limit the people in 5) unless we need to. And to be 
clear, if we actually need to, then I'm fine with doing that... It's just that 
-- like I said earlier in this message -- I don't clearly understand why this 
is a problem. That said, there are multiple people more knowledgable tha

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

[David Sweeris via swift-evolution]

> On Oct 2, 2017, at 7:57 PM, Xiaodi Wu  wrote:
> 
> On Mon, Oct 2, 2017 at 9:04 PM, David Sweeris  > wrote:
> 
> On Oct 2, 2017, at 5:45 PM, Xiaodi Wu via swift-evolution 
> > wrote:
> 
>> On Mon, Oct 2, 2017 at 19:28 Ethan Tira-Thompson via swift-evolution 
>> > wrote:
>> I’m all for fixing pressing issues requested by Xiaodi, but beyond that I 
>> request we give a little more thought to the long term direction.
>> 
>> My 2¢ is I’ve been convinced that very few characters are “obviously” either 
>> a operator or identifier across all contexts where they might be used.  Thus 
>> relegating the vast majority of thousands of ambiguous characters to 
>> committee to decide a single global usage.  But that is both a huge time 
>> sink and fundamentally flawed in approach due to the contextual dependency 
>> of who is using them.
>> 
>> For example, if a developer finds a set of symbols which perfectly denote 
>> some niche concept, do you really expect the developer to submit a proposal 
>> and wait months/years to get the characters classified and then a new 
>> compiler version to be distributed, all so that developer can adopt his/her 
>> own notation?
>> 
>> The Unicode Consortium already has a document describing which Unicode 
>> characters are suitable identifiers in programming languages, with guidance 
>> as to how to customize that list around the edges. This is already adopted 
>> by other programming languages. So, with little design effort, that task is 
>> not only doable but largely done.
>> 
>> As to operators, again, I am of the strong opinion that making it possible 
>> for developers to adopt any preferred notation for any purpose (a) is 
>> fundamentally incompatible with the division between operators and 
>> identifiers, as I believe you’re saying here; and (b) should be a non-goal 
>> from the outset. The only task, so far as I can tell, left to do is to 
>> identify what pragmatic set of (mostly mathematical) symbols are used as 
>> operators in the wider world and are likely to be already used in Swift code 
>> or part of common use cases where an operator is clearly superior to 
>> alternative spellings. In my view, the set of valid operator characters not 
>> only shouldn’t require parsing or import directives, but should be small 
>> enough to be knowable by memory.
> 
> The set notation operators should be identifiers, then?
> 
> Set notation operators aren't valid identifier characters; to be clear, the 
> alternative to being a valid operator character would be simply not listing 
> that character among valid operator or identifier characters.
>  
> Because the impression I got from the Set Algebra proposal a few months ago 
> is that there are a lot of people who’ve never even seen those operators, let 
> alone memorized them.
> 
> That's not the impression I got; the argument was that these symbols are hard 
> to type and _not more recognizable that the English text_, which is certainly 
> a plausible argument and the appropriate bar for deciding on a standard 
> library API name.
> 
> MHO is that the bar for a potentially valid operator character _for potential 
> use in third-party APIs_ needn't be so high that we demand the character to 
> be more recognizable to most people than alternative notations. Instead, we 
> can probably justify including a character if it is (a) plausibly useful for 
> some relatively common Swift use case and (b) at least somewhat recognizable 
> for many people. Since set algebra has a well-accepted mathematical notation 
> that's taught (afaict) at the _high school_ level if not earlier, and since 
> set algebra functions are a part of the standard library, that surely meets 
> those bars of usefulness and recognizability.
Maybe they've started teaching it earlier than when I went through school... I 
don't think I learned it until Discrete Math, which IIRC was a 2nd or 3rd year 
course at my college and only required for Math, CS, and maybe EE majors. 
Anyway, WRT a), if Swift achieves its "take over the world" goal, all use cases 
will be Swift use cases. WRT b), "many" as in the numerical quantity or "many" 
as in the percentage? There are probably millions of people who recognize 
calculus's operators, but there are 7.5 billion people in the world.

> Keep in mind that Swift already goes far above and beyond in terms of 
> operators
Yep, that's is a large part of why I'm such a Swift fan :-D

> in that: (a) it allows overloading of almost all standard operators; (b) it 
> permits the definition of effectively an infinite number of custom operators 
> using characters found in standard operators; (c) it permits the definition 
> of custom precedences for custom operators; and (d) it additionally permits 
> the use of a wide number of Unicode 

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

[David Sweeris via swift-evolution]

> On Oct 2, 2017, at 6:52 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> Thanks for hoisting this out into its own thread, Jordan. I was hesitant to 
> elaborate more on another access level thread :)
> 
> I think the change should absolutely be made. Even though the "private" 
> keyword occurs at the file level, the description of the feature in the Swift 
> documentation simply states: "you can mark an extension with an explicit 
> access-level modifier to set a new default access level for all members 
> defined within the extension." To me, that implies that "private extension 
> Foo { func bar() }" should be identical to "extension Foo { private func 
> bar() }", but today it becomes equivalent to "extension Foo { fileprivate 
> func bar() }".
> 
> That seems fundamentally broken, because (1) it's inconsistent, (2) "private 
> extension" and "fileprivate extension" are two ways of saying the same thing, 
> non-intuitively, and (3) there's no way for someone to use the shorthand 
> syntax to take advantage of the new meaning of private within same-file type 
> extensions.
> 
> While I personally never use the shorthand extension access level feature 
> (because I prefer the explicit form, and because of situations like this 
> one), I definitely think it should be consistent for people who do want to 
> use it.
> 
> I wonder how much existing code would be affected by this change. Do people 
> use "private extension" when they really want "fileprivate extension"? I 
> would hope the number of users affected would be few, at least.

I don’t think I’ve ever used “private extension”, but if I did, I’d expect it 
to not mean “fileprivate extension”.

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

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

[David Sweeris via swift-evolution]

> On Oct 2, 2017, at 5:45 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Mon, Oct 2, 2017 at 19:28 Ethan Tira-Thompson via swift-evolution 
>>  wrote:
>> I’m all for fixing pressing issues requested by Xiaodi, but beyond that I 
>> request we give a little more thought to the long term direction.
>> 
>> My 2¢ is I’ve been convinced that very few characters are “obviously” either 
>> a operator or identifier across all contexts where they might be used.  Thus 
>> relegating the vast majority of thousands of ambiguous characters to 
>> committee to decide a single global usage.  But that is both a huge time 
>> sink and fundamentally flawed in approach due to the contextual dependency 
>> of who is using them.
>> 
>> For example, if a developer finds a set of symbols which perfectly denote 
>> some niche concept, do you really expect the developer to submit a proposal 
>> and wait months/years to get the characters classified and then a new 
>> compiler version to be distributed, all so that developer can adopt his/her 
>> own notation?
> 
> The Unicode Consortium already has a document describing which Unicode 
> characters are suitable identifiers in programming languages, with guidance 
> as to how to customize that list around the edges. This is already adopted by 
> other programming languages. So, with little design effort, that task is not 
> only doable but largely done.
> 
> As to operators, again, I am of the strong opinion that making it possible 
> for developers to adopt any preferred notation for any purpose (a) is 
> fundamentally incompatible with the division between operators and 
> identifiers, as I believe you’re saying here; and (b) should be a non-goal 
> from the outset. The only task, so far as I can tell, left to do is to 
> identify what pragmatic set of (mostly mathematical) symbols are used as 
> operators in the wider world and are likely to be already used in Swift code 
> or part of common use cases where an operator is clearly superior to 
> alternative spellings. In my view, the set of valid operator characters not 
> only shouldn’t require parsing or import directives, but should be small 
> enough to be knowable by memory.

The set notation operators should be identifiers, then? Because the impression 
I got from the Set Algebra proposal a few months ago is that there are a lot of 
people who’ve never even seen those operators, let alone memorized them.

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

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

[David Sweeris via swift-evolution]

> On Oct 2, 2017, at 3:24 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
>> On Mon, Oct 2, 2017 at 12:58 PM, David Sweeris <daveswee...@mac.com> wrote:
>> 
>>> On Oct 2, 2017, at 09:14, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>> 
>>> What is your use case for this?
>>> 
>>>> On Mon, Oct 2, 2017 at 10:56 David Sweeris via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>>> On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution 
>>>>> <swift-evolution@swift.org> wrote:
>>>>> 
>>>>> 
>>>>>> On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution 
>>>>>> <swift-evolution@swift.org> wrote:
>>>>>> 
>>>>>> Hi All.
>>>>>> 
>>>>>> I’d like to help as well. I have fun with operators.
>>>>>> 
>>>>>> There is also the issue of code security with invisible unicode 
>>>>>> characters and characters that look exactly alike.
>>>>> 
>>>>> Unless there is a compelling reason to add them, I think we should ban 
>>>>> invisible characters.  What is the harm of characters that look alike?
>>>> 
>>>> Especially if people want to use the character in question as both an 
>>>> identifier and an operator: We can make the character an identifier and 
>>>> its lookalike an operator (or the other way around).
>> 
>> Off the top of my head...
>> In calculus, “햽” (MATHEMATICAL SANS-SERIF SMALL D) would be a fine 
>> substitute for "d" in “햽y/햽x” ("the derivative of y(x) with respect to x").
>> In statistics, we could use "햢" (MATHEMATICAL SANS-SERIF CAPITAL C), as in 
>> "5햢3" to mimic the "5C3" notation ("5 choose 3"). And although not strictly 
>> an issue of identifiers vs operators, “！” (FULLWIDTH EXCLAMATION MARK) would 
>> be an ok substitution (that extra space on the right looks funny) for "!" in 
>> “4！” ("4 factorial").
>> 
>> I'm sure there are other examples from math/science/> "symbology"-heavy DSL here>, but “d” in particular is one that I’ve wanted 
>> for a while since Swift classifies "∂" (the partial derivative operator) as 
>> an operator rather than an identifier, making it impossible to use a 
>> consistent syntax between normal derivatives and partial derivatives (normal 
>> derivatives are "d(y)/d(x)", whereas partial derivatives get to drop the 
>> parens "∂y/∂x")
> 
> I think we should specify from the outset of re-examining this topic that 
> supporting arbitrary math/science notation without demonstrable improvement 
> in code clarity for actual, Swift code is a non-goal.

I gave up on trying to get the restrictions on the normal "!" removed a while 
ago... I guess we'll just have to agree to disagree on !-lookalikes.

Supporting arbitrary math/science notation, though, is almost by definition an 
increase in code clarity for the people who are used to it. Is that everyone? 
Of course not. Is it the majority? I doubt it; the days when Computer Science 
was part of the Math department are long gone, and it's common for people to 
become developers without getting any formal education in the field at all 
(which is great, IMHO... that means we're successfully making computing more 
accessible). That doesn't seem to me like a good reason not to support such 
symbolic notations, though. I'm not suggesting a change to the standard library 
here, to be forced on everyone -- I'm merely suggesting a way to help people 
who prefer the more symbol-heavy notations to use them if they and their teams 
(and their clients, if they're a library vendor) want to.

I would never claim that the particular cases I raised are “critical to Swift's 
long-term success” or anything (I think the # of people who care about "햽y" vs 
"d(y)" enough to let it dictate their language choice is probably zero), but I 
would like to point out that a few of the threads here have demonstrated just 
how differing the opinions are on this matter even within the relatively small 
group of people who participate on this list. If Swift’s long-term goal is to 
take over the world, that means the language needs to “work” for very diverse 
groups of people... We probably shouldn’t be restricting syntax at the language 
level unless we actually have to.

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

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

[David Sweeris via swift-evolution]

On Oct 2, 2017, at 09:14, Xiaodi Wu <xiaodi...@gmail.com 
<mailto:xiaodi...@gmail.com>> wrote:

> What is your use case for this?
> 
> On Mon, Oct 2, 2017 at 10:56 David Sweeris via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
> On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>>> On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Hi All.
>>> 
>>> I’d like to help as well. I have fun with operators.
>>> 
>>> There is also the issue of code security with invisible unicode characters 
>>> and characters that look exactly alike.
>> 
>> Unless there is a compelling reason to add them, I think we should ban 
>> invisible characters.  What is the harm of characters that look alike?
> 
> Especially if people want to use the character in question as both an 
> identifier and an operator: We can make the character an identifier and its 
> lookalike an operator (or the other way around).

Off the top of my head...
In calculus, “햽” (MATHEMATICAL SANS-SERIF SMALL D) would be a fine substitute 
for "d" in “햽y/햽x” ("the derivative of y(x) with respect to x").
In statistics, we could use "햢" (MATHEMATICAL SANS-SERIF CAPITAL C), as in 
"5햢3" to mimic the "5C3" notation ("5 choose 3"). And although not strictly an 
issue of identifiers vs operators, “！” (FULLWIDTH EXCLAMATION MARK) would be an 
ok substitution (that extra space on the right looks funny) for "!" in “4！” ("4 
factorial").

I'm sure there are other examples from math/science/, but “d” in particular is one that I’ve wanted for 
a while since Swift classifies "∂" (the partial derivative operator) as an 
operator rather than an identifier, making it impossible to use a consistent 
syntax between normal derivatives and partial derivatives (normal derivatives 
are "d(y)/d(x)", whereas partial derivatives get to drop the parens "∂y/∂x")

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

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

[David Sweeris via swift-evolution]

> On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution 
>>  wrote:
>> 
>> Hi All.
>> 
>> I’d like to help as well. I have fun with operators.
>> 
>> There is also the issue of code security with invisible unicode characters 
>> and characters that look exactly alike.
> 
> Unless there is a compelling reason to add them, I think we should ban 
> invisible characters.  What is the harm of characters that look alike?

Especially if people want to use the character in question as both an 
identifier and an operator: We can make the character an identifier and its 
lookalike an operator (or the other way around).

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

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

[David Sweeris via swift-evolution]

> On Sep 30, 2017, at 16:13, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I’m happy to participate in the reshaping of the proposal. It would be nice 
> to gather a group of people again to help drive it forward.
> 
> That said, it’s unclear to me that superscript T is clearly an operator, any 
> more than would be superscript H (Hermitian), superscript 2, superscript 3, 
> etc. But at any rate, this would be discussion for the future workgroup.

Superscript T’s only regular use that I’m aware of is as the transpose operator 
for vectors and matrices. I’m certainly not omniscient, though.

Are we going to attempt to distinguish between characters like these two?
ⁿ (SUPERSCRIPT LATIN SMALL LETTER N Unicode: U+207F, UTF-8: E2 81 BF)
n (LATIN SMALL LETTER N Unicode: U+006E, UTF-8: 6E), with a superscript format 
applied

- Dave Sweerisn

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

Re: [swift-evolution] Enums and Source Compatibility

[David Sweeris via swift-evolution]

> On Sep 28, 2017, at 4:15 PM, Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> Agreed, I am not seeing this change doing so much good because maybe it could 
> prevent issues Library writers or developers updating libraries without 
> checking things... not trying to be rude and/or non empathetic, but 
> exhaustive enums never struck me as a bad thing and the reasons why they 
> could be bad very quickly leads one to think “maybe you should not have been 
> switching on enums there...”.

You're suggesting that we use enums when something is known to be exhaustive, 
and then something like this when it's not?

struct SomeOptionSetOrWhatever : Equatable, RawRepresentable {
public static func == (lhs: SomeOptionSetOrWhatever, rhs: 
SomeOptionSetOrWhatever) -> Bool { return lhs.value == rhs.value  }
public static let optionOne = SomeOptionSetOrWhatever(privateInit: 1)
public static let optionTwo = SomeOptionSetOrWhatever(privateInit: 2)
private let value: Int
private init(privateInit value: Int) { self.value = value }
public init?(rawValue: Int) {
switch rawValue {
case 1: self = .optionOne
case 2: self = .optionTwo
case _: value = 0; return nil
}
}
public var rawValue: Int { return value }
}

func foo(x: SomeOptionSetOrWhatever) {
switch x {
case .optionOne: print("first option")
case .optionTwo: print("second option")
default: break //without this line, it's a "switch much be exhaustive" 
error
}
}

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

Re: [swift-evolution] Enums and Source Compatibility

[David Sweeris via swift-evolution]

> On Sep 20, 2017, at 4:15 PM, Dave DeLong via swift-evolution 
>  wrote:
> 
> Hi Jordan,
> 
> One thing I’m still not clear on exhaustive vs non-exhaustive…
> 
> What will stop a developer from releasing an exhaustive enum in version 1 of 
> their library, and then adding a new case in version 2?

Nothing, other than it would break code written using version 1.

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

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

[David Sweeris via swift-evolution]

> On Sep 12, 2017, at 8:07 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> But all that stuff about custom attributes and metaprogramming introspection 
> is a big topic of it's own that isn't going to be solved in Swift 5, so this 
> is a bit of a digression. :)

Is it really a digression, though? Seems like with source-compatibility being 
essentially required going forward, it's important to nail this stuff down 
sooner rather than later if we want a nice, consistent language for The Future™.

I mean, the idea of writing "@adjective var noun: Type" to indicate that a 
certain variable shouldn't take place in code synthesis seems fairly safe to 
me, but proving $Idea1 is generalizable without stepping on $Idea2 is outside 
my area of expertise.



> On Sep 12, 2017, at 8:07 PM, Tony Allevato via swift-evolution 
>  wrote:
> On Tue, Sep 12, 2017 at 7:10 PM Xiaodi Wu  > wrote:
> On Tue, Sep 12, 2017 at 9:58 AM, Thorsten Seitz via swift-evolution 
> > wrote:
> Good arguments, Tony, you have convinced me on all points. Transient is the 
> way to go. Thank you for your patience!
> 
> On many points, I agree with Tony, but I disagree that "transient" addresses 
> the issue at hand. The challenge being made is that, as Gwendal puts it, it's 
> _unwise_ to have a default implementation, because people might forget that 
> there is a default implementation. "Transient" only works if you remember 
> that there is a default implementation, and in that case, we already have a 
> clear syntax for overriding the default.
> 
> Right—I hope it hasn't sounded like I'm conflating the two concepts 
> completely. The reason I brought up "transient" is because nearly all of the 
> "risky" examples being cited so far have been of the variety "I have a type 
> where some properties happen to be Equatable but shouldn't be involved in 
> equality", so my intention has been to show that if we have a better solution 
> to that specific problem (which is, related to but not the same as the 
> question at hand), then there aren't enough risky cases left to warrant 
> adding this level of complexity to the protocol system.
>  
> 
> As others point out, there's a temptation here to write things like 
> "transient(Equatable)" so as to control the synthesis of implementations on a 
> per-protocol basis. By that point, you've invented a whole new syntax for 
> implementing protocol requirements. (Ah, you might say, but it's hard to 
> write a good hashValue implementation: sure, but that's adequately solved by 
> a library-supplied combineHashes() function.)
> 
> I totally agree with this. A design that would try to annotate "transient" 
> with a protocol or list of protocols is missing the point of the semantics 
> that "transient" is supposed to provide. It's not a series of switches to 
> that can be flipped on and off for arbitrary protocols—it's a semantic tag 
> that assigns additional meaning to properties and certain protocols (such as 
> Equatable, Hashable, and Codable, but possibly others that haven't been 
> designed yet) would have protocol-specific behavior for those properties.
> 
> To better explain what I've been poking at, I'm kind of extrapolating this 
> out to a possible future where it may be possible to more generally (1) 
> define custom @attributes in Swift, like Java annotations, and then (2) use 
> some metaprogramming constructs to generate introspective default 
> implementations for a protocol at compile-time just as the compiler does 
> "magically" now, and the generator would be able to query attributes that are 
> defined by the same library author as the protocol and handle them 
> accordingly.
> 
> In a world where that's possible, I think it's less helpful to think in terms 
> of "I need to distinguish between conforming to X and getting a synthesized 
> implementation and conforming to X and avoiding the synthesized 
> implementation because the default might be risky", but instead to think in 
> terms of "How can I provide enough semantic information about my types to 
> remove the risk?"
> 
> In other words, the switches we offer developers to flip shouldn't be about 
> turning on/off entire features, but about giving the compiler enough 
> information to make it smart enough that we never need to turn it off in the 
> first place. As I alluded to before, if I have 10 properties in a type and 
> only 1 of those needs to be ignored in ==/hashValue/whatever, writing 
> "Equatable" instead of "derives Equatable" isn't all that helpful. Yes, it 
> spits out an error message where there wouldn't have been one, but it doesn't 
> reduce any of the burden of having to provide the appropriate manual 
> implementation.

Speaking of which, what do you suppose the hit/miss ratio would be WRT 
synthesized `Equatable`, etc, if we introduced 

Re: [swift-evolution] pure functions

[David Sweeris via swift-evolution]

> On Sep 9, 2017, at 10:48 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> on Wed Aug 23 2017, Joe Groff  wrote: 
 On Aug 18, 2017, at 12:10 PM, Chris Lattner via swift-evolution 
  wrote:  Splitting this out from the 
 concurrency thread:  
 
> On Aug 18, 2017, at 6:12 AM, Matthew Johnson  
> wrote: 
>> On Aug 17, 2017, at 11:53 PM, Chris Lattner  wrote: 
>>  
>> In the manifesto you talk about restrictions on passing functions across 
>> an actor message.  You didn’t discuss pure functions, presumably because 
>> Swift doesn’t have them yet. I imagine that if (hopefully when) Swift 
>> has compiler support for verifying pure functions these would also be 
>> safe to pass across an actor message.  Is that correct? 
> Correct.  The proposal is specifically/intentionally designed to be light 
> on type system additions, but there are many that could make it better in 
> various ways.  The logic for this approach is that I expect *a lot* of 
> people will be writing mostly straight-forward concurrent code, and that 
> goal is harmed by presenting significant type system hurdles for them to 
> jump over, because that implies a higher learning curve.   This is why 
> the proposal doesn’t focus on a provably memory safe system: If someone 
> slaps “ValueSemantical” on a type that doesn’t obey, they will break the 
> invariants of the system.  There are lots of ways to solve that problem 
> (e.g. the capabilities system in Pony) but it introduces a steep learning 
> curve.   I haven’t thought a lot about practically getting pure functions 
> into Swift, because it wasn’t clear what problems it would solve (which 
> couldn’t be solved another way).  You’re right though that this could be 
> an interesting motivator. 
 I can provide a concrete example of why this is definitely and important 
 motivator. My current project uses pure functions, value semantics and 
 declarative effects at the application level and moves as much of the 
 imperative code as possible (including effect handling) into library level 
 code. This is working out really well and I plan to continue with this 
 approach.  The library level code needs the ability to schedule user code 
 in the appropriate context.  There will likely be some declarative ability 
 for application level code to influence the context, priority, etc, but it 
 is the library that will be moving the functions to the final context.  
 They are obviously not closure literals from the perspective of the 
 library.   Pure functions are obviously important to the semantics of this 
 approach.  We can get by without compiler verification, using 
 documentation just as we do for protocol requirements that can't be 
 verified.  That said, it would be pretty disappointing to have to avoid 
 using actors in the implementation simply because we can't move pure 
 functions from one actor to another as necessary.   To be clear, I am 
 talking in the context of "the fullness of time".  It would be perfectly 
 acceptable to ship actors before pure functions. That said, I do think 
 it's crucial that we eventually have the ability to verify pure functions 
 and move them around at will. 
>>> Right.  Pure functions are also nice when you care about thread safety, and 
>>> there is a lot of work on this.  C has __attribute__((const)) and ((pure)) 
>>> for example, c++ has constexpr, and many research languages have built full 
>>> blown effects systems.   My principle concern is that things like this 
>>> quickly become infectious: LOTS of things are pure functions, and requiring 
>>> them all to be marked as such becomes a lot of boilerplate and conceptual 
>>> overhead.  This is happening in the C++ community with constexpr for 
>>> example. The secondary concern is that you need to build out the model 
>>> enough that you don’t prevent abstractions.  A pure function should be able 
>>> to create an instance of a struct, mutate it (i.e. calling non-pure 
>>> functions) etc.  This requires a non-trivial design, and as the design 
>>> complexity creeps, you run the risk of it getting out of control. 
>> Now that inout parameters are guaranteed exclusive, a mutating method on a 
>> struct or a function that takes inout parameters is isomorphic to one that 
>> consumes the initial value as a pure argument and returns the modified value 
>> back. This provides a value-semantics-friendly notion of purity, where a 
>> function can still be considered pure if the only thing it mutates is its 
>> unescaped local state and its inout parameters and it doesn't read or write 
>> any shared mutable state such as mutable globals, instance properties, or 
>> escaped variables. 

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

[David Sweeris via swift-evolution]

> On Aug 31, 2017, at 4:54 PM, Dave DeLong  wrote:
> 
>> 
>> On Aug 31, 2017, at 5:45 PM, David Sweeris > > wrote:
>> 
>>> 
>>> On Aug 31, 2017, at 3:17 PM, Dave DeLong >> > wrote:
>>> 
 
 On Aug 31, 2017, at 3:58 PM, David Sweeris > wrote:
 
 
> On Aug 31, 2017, at 2:51 PM, Dave DeLong via swift-evolution 
> > wrote:
> 
> Just a side observation…
> 
> One of the downsides I would put forward to notation like this is it 
> massively increases the barrier to entry for anyone else. I look at that 
> “Reduction.agda” file and wonder if I need to go back to school for a 
> degree in Math just to understand what’s going on.
> 
> On the other hand, while using inefficient matrix notation may be more 
> verbose, it is consistent with the other notation used in programming, 
> which means it is more easily understandable for new-comers to the code.
 
 New-comers from where? I've met more than one mathematician or physicist 
 who claims they can't code because the syntax isn't what they're used to. 
 People with different backgrounds can and do have vastly different ideas 
 about what constitutes an intuitive syntax for any given semantic (which 
 why I disagree with the notion that having more than one spelling for 
 stuff is inherently bad).
>>> 
>>> That’s a fair point, which IMO reinforces the notion that changes like this 
>>> should be an editor-level feature, and not a code-level feature.
>>> 
>>> An editor can reformat code (using a font with bazillions of ligatures or 
>>> whatever) in was that you wouldn’t want to necessarily “hard code”.
>> 
>> To clarify, you're suggesting we do something like this?
>> @prettyprint(prefix operator "Σ", /*probably some CSS or something for 
>> telling the editor where to position the arguments relative to the operator, 
>> whether they're rendered with subscript vs superscript vs normal, etc */)
>> func sum  (indicies: S, term: (S.Element) -> T) -> 
>> T {
>>   return indicies.reduce(0) { $0 + term($1) }
>> }
>> 
>> Technically speaking, yeah, sure, such a system could be made to work. I 
>> don't see it getting much support outside of Xcode, though, unless you can 
>> convince other languages to adopt the same convention. We'd want people's 
>> choice of display style to be driven by personal preference, not whether 
>> they can integrate Xcode into their workflow. Speaking of workflows, how far 
>> from "plain text" do you think we can get before people start thinking that 
>> you need a mac running Xcode to program in Swift?
>> 
>> - Dave Sweeris
> 
> Perhaps… I’m fully admitting up-front that this is all really hand-wavy and 
> we’re probably veering a bit off-topic, since this is getting more in to 
> “editor-evolution” rather than “swift-evolution”.
> 
> But yes, if an editor had some sort of intrinsic knowledge about the purpose 
> of a line of code, then it could visually “rewrite” a summation function 
> using a Σ. Or if it knew about matrix types, perhaps it could render the 
> matrix in the 2D format that is standard to matrix notation. Or it could 
> replace UIImage(named: “someConstant”) with the rendered image literal, 
> without actually requiring the explicit underlying image literal syntax.
> 
> A grossly simplified comparison is that good markdown editors don’t just show 
> the plaintext for the markdown you’re writing, but will also `stylize` *code* 
> _correctly_ **as** *`you write it`*.

Aside from the bits about matrices and other things that drastically change the 
line height, the I think that comparison is only grossly simplified from the 
PoV of an editor's author(s).

What about the issue of different spelling conventions? It's all well and good 
for the editor to display "pow(x, 2)" as "x²", but I've never used a system 
where something that's displayed as "x²" isn't typed as "x^2" (of course, now 
that I've said that, someone will probably come up with 53 counter-examples). 
If the editor is rendering a line of code like "let y = log₃(sin²(∫x³dx))" and 
I add a "+ x^2" to the end, it's probably going to take me a while to find the 
bug because years of math nerdery (sp?) have trained my brain to think that, 
when I'm "mathing", "x^2" and "x²" are equivalent statements, kinda like 
they're just written in different fonts or something. Now, clearly the fault 
would be mine (because, despite all the math symbols, I'd be programming, not 
mathing), but if we were to get such a system, I bet that mistake would make 
the list of "Top 10 Bugs Math People Create in Swift", and it it feels 
antithetical to a language that generally goes out of its way to prevent such 
simple errors. The only practical solution I can think of is a 

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

[David Sweeris via swift-evolution]

> On Aug 31, 2017, at 6:27 PM, John McCall via swift-evolution 
>  wrote:
> 
> I would argue that there is a much broader philosophical truth here.  
> Programming is not, and never can be, a pure exercise in mathematics, and the 
> concepts necessary for understanding programming are related to but 
> ultimately different from the concepts necessary for understanding 
> mathematics.  That is, Dave Sweeris's mathematicians and physicists are 
> almost certainly misunderstanding their confusion: saying that the syntax is 
> wrong implies that there could be a syntax that could be right, i.e. a syntax 
> that would allow them to simply program in pure mathematics.

I don't think any of them claimed that any particular programming language's 
syntax was wrong, just that they were confused by it. I only have a clear(ish) 
recollection of one of them -- the others were too long ago -- and he said 
something along the lines of "Mathematica is as close as I get to programming 
because I don't have time to learn how the CS people write things" (and I think 
his hand was forced WRT learning even just that, because Mathematica was part 
of a class he was teaching). Anyway, at the time, his sentiment struck me as 
"not unique", so I'd guess that it tickled a memory of someone(s) expressing 
somewhat similar views to me before. To be clear, I'm not claiming that view 
towards programming is common in the general mathematician/physicist 
population... When I find out someone's an expert in some field in math or 
physics, I'll probably talk to them about that; programming isn't a subject I'd 
be likely to raise unless their area of expertise is "Computational Whatever". 
So not only is my dataset far too small, and merely anecdotal, it also suffers 
from selection bias.

Anyway, the point I'm taking my own sweet time getting to is that if Swift's 
goal is world domination, I think a good place to start with the scientific 
community could be to let them use the same syntax they learned while spending 
the better part of decade or more studying. Obviously, Swift already goes a 
long way towards that goal by allowing custom unicode operators and such, but 
if you're telling me that getting prettyprint might be in-scope(ish), too... 
Well, I still think that in the long run that problem should to be solved by 
the OS so that whatever data that ends up getting prettyprinted as "x²" will 
render that same way in every application, even when sent to the console via 
`print()` or `cout`. In the meantime I won't complain if the first step towards 
that goal is getting it in the editor, but I worry that such an approach would 
lead to us creating the 15th standard (https://xkcd.com/927/ 
). And it's like my momma always said, "you should be 
part of the solution, not part of the precipitate".

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

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

[David Sweeris via swift-evolution]

> On Aug 31, 2017, at 4:54 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> (Also, I really doubt changing concatenation to `++` is going to fly. Swift 
> is not Haskell.)

Of course not... the concatenation operator should be `|` 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

[David Sweeris via swift-evolution]

> On Aug 31, 2017, at 3:17 PM, Dave DeLong  wrote:
> 
>> 
>> On Aug 31, 2017, at 3:58 PM, David Sweeris > > wrote:
>> 
>> 
>>> On Aug 31, 2017, at 2:51 PM, Dave DeLong via swift-evolution 
>>> > wrote:
>>> 
>>> Just a side observation…
>>> 
>>> One of the downsides I would put forward to notation like this is it 
>>> massively increases the barrier to entry for anyone else. I look at that 
>>> “Reduction.agda” file and wonder if I need to go back to school for a 
>>> degree in Math just to understand what’s going on.
>>> 
>>> On the other hand, while using inefficient matrix notation may be more 
>>> verbose, it is consistent with the other notation used in programming, 
>>> which means it is more easily understandable for new-comers to the code.
>> 
>> New-comers from where? I've met more than one mathematician or physicist who 
>> claims they can't code because the syntax isn't what they're used to. People 
>> with different backgrounds can and do have vastly different ideas about what 
>> constitutes an intuitive syntax for any given semantic (which why I disagree 
>> with the notion that having more than one spelling for stuff is inherently 
>> bad).
> 
> That’s a fair point, which IMO reinforces the notion that changes like this 
> should be an editor-level feature, and not a code-level feature.
> 
> An editor can reformat code (using a font with bazillions of ligatures or 
> whatever) in was that you wouldn’t want to necessarily “hard code”.

To clarify, you're suggesting we do something like this?
@prettyprint(prefix operator "Σ", /*probably some CSS or something for telling 
the editor where to position the arguments relative to the operator, whether 
they're rendered with subscript vs superscript vs normal, etc */)
func sum  (indicies: S, term: (S.Element) -> T) -> T {
  return indicies.reduce(0) { $0 + term($1) }
}

Technically speaking, yeah, sure, such a system could be made to work. I don't 
see it getting much support outside of Xcode, though, unless you can convince 
other languages to adopt the same convention. We'd want people's choice of 
display style to be driven by personal preference, not whether they can 
integrate Xcode into their workflow. Speaking of workflows, how far from "plain 
text" do you think we can get before people start thinking that you need a mac 
running Xcode to program in Swift?

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

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

[David Sweeris via swift-evolution]

> On Aug 31, 2017, at 2:51 PM, Dave DeLong via swift-evolution 
>  wrote:
> 
> Just a side observation…
> 
> One of the downsides I would put forward to notation like this is it 
> massively increases the barrier to entry for anyone else. I look at that 
> “Reduction.agda” file and wonder if I need to go back to school for a degree 
> in Math just to understand what’s going on.
> 
> On the other hand, while using inefficient matrix notation may be more 
> verbose, it is consistent with the other notation used in programming, which 
> means it is more easily understandable for new-comers to the code.

New-comers from where? I've met more than one mathematician or physicist who 
claims they can't code because the syntax isn't what they're used to. People 
with different backgrounds can and do have vastly different ideas about what 
constitutes an intuitive syntax for any given semantic (which why I disagree 
with the notion that having more than one spelling for stuff is inherently bad).

- Dave Sweeris

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

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

[David Sweeris via swift-evolution]

> On Aug 30, 2017, at 8:21 AM, John Pratt via swift-evolution 
>  wrote:
> 
> I agree with what you said and I wonder myself if it is possible at this
> time for Swift to do what I mentioned in that article, given the current
> roadmap.
> 
> Everyone would have to rewrite the agenda of Swift 5 to incorporate 
> most of what I was talking about.  Additionally, Swift's
> syntax and XCode would begin to overlap.  It would definitely require a "smart
> editor," but then I also think that all terminals should be smart likewise.
> The distinction between code and code editor would become less clear.

However pretty printing things like matrices get handled, if that isn't simply 
part of the OS's text handling facilities, every "smart" editor will handle it 
differently (like different HTML rendering engines, except without the common 
HTML spec) and the "dumb" editors will show something that's shockingly 
different. It really seems to me that getting good, consistent support for 
"multi-line lines" in regular text editors will probably take a new OS which 
has that functionality baked-in its APIs at a low enough level that there isn't 
a way to not support it without just completely rolling your own text system (I 
suppose removing and replacing the existing APIs would work, too, but from a 
certain PoV that essentially is a new OS). In particular, if rows are no longer 
fixed-height, you've decoupled the cursor's logical position from its on-screen 
position... apps that were written/compiled before pretty print came into the 
API would render everything after an extra tall line at the wrong y position.

I think getting easy unicode input is probably doable for the big three OSs, 
though, especially if the USB consortium would release a unicode-aware HID spec.

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

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

[David Sweeris via swift-evolution]

On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution 
> wrote:

> I sent a postal envelope to the Swift team with an article I wrote, arguing 
> that
> symbols and graphics would push the programming language forward.
> 
> Wouldn’t it be nice to have an actual multiplication matrix broken out into 
> code,
> instead of typing, “matrix()”?  It seems to me Swift has the chance to do 
> that.
> 
> Also: why does "<==" still reside in code as "less than or equal to” when
> there is a unicode equivalent that looks neat?  
> 
> Why can’t the square of x have a superscript of 2 instead of having 
> “pow(x,2)?  
> I think this would make programming much easier to deal with.
> 
> I expound on this issue in my article:
> 
> http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf 
> 
> 
> Thank you for reading.

I whole-heartedly agree with the sentiment, but I think you're approaching this 
from the wrong direction... Unicode isn't used much because there's no simple, 
easy, and universal way to input unicode characters. Personally, I use a custom 
keyboard layout with tons of stuff mapped to ctrl- and alt-keys, but that 
breaks things like, say, Terminal.app, because ctrl-d prints ∂ instead of 
sending the control character (so I switch back to a keyboard layout without 
the control keys mapped, which is annoying). We need to solve the general 
unicode input problem before we can start seriously pushing for its use to be 
required, and that's far outside of Swift's scope.

As far as formatting matrices "correctly" (and I also wish they could be 
displayed the way you demonstrated in your write-up), I think that'd be more a 
feature of some sort of custom display layer in Xcode than of macOS's or 
Linux's text system. Maybe it'd fit in with some other OS's type system, but 
"typewriter text" is too ingrained into the text systems of Windows, macOS, and 
Linux (and every other OS I can think of) for "pretty print" matrices to work 
across all text-based applications (which is what I think it'd take to catch 
on).

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

Re: [swift-evolution] pure functions

[David Sweeris via swift-evolution]

> On Aug 18, 2017, at 12:11, Chris Lattner via swift-evolution 
>  wrote:
> 
> Splitting this out from the concurrency thread:
> 
>> 
>>> On Aug 18, 2017, at 6:12 AM, Matthew Johnson  wrote:
 On Aug 17, 2017, at 11:53 PM, Chris Lattner  wrote:
 
 In the manifesto you talk about restrictions on passing functions across 
 an actor message.  You didn’t discuss pure functions, presumably because 
 Swift doesn’t have them yet.  I imagine that if (hopefully when) Swift has 
 compiler support for verifying pure functions these would also be safe to 
 pass across an actor message.  Is that correct?
>>> 
>>> Correct.  The proposal is specifically/intentionally designed to be light 
>>> on type system additions, but there are many that could make it better in 
>>> various ways.  The logic for this approach is that I expect *a lot* of 
>>> people will be writing mostly straight-forward concurrent code, and that 
>>> goal is harmed by presenting significant type system hurdles for them to 
>>> jump over, because that implies a higher learning curve.
>>> 
>>> This is why the proposal doesn’t focus on a provably memory safe system: If 
>>> someone slaps “ValueSemantical” on a type that doesn’t obey, they will 
>>> break the invariants of the system.  There are lots of ways to solve that 
>>> problem (e.g. the capabilities system in Pony) but it introduces a steep 
>>> learning curve.
>>> 
>>> I haven’t thought a lot about practically getting pure functions into 
>>> Swift, because it wasn’t clear what problems it would solve (which couldn’t 
>>> be solved another way).  You’re right though that this could be an 
>>> interesting motivator. 
>> 
>> I can provide a concrete example of why this is definitely and important 
>> motivator.  
>> 
>> My current project uses pure functions, value semantics and declarative 
>> effects at the application level and moves as much of the imperative code as 
>> possible (including effect handling) into library level code.  This is 
>> working out really well and I plan to continue with this approach.  The 
>> library level code needs the ability to schedule user code in the 
>> appropriate context.  There will likely be some declarative ability for 
>> application level code to influence the context, priority, etc, but it is 
>> the library that will be moving the functions to the final context.  They 
>> are obviously not closure literals from the perspective of the library.
>> 
>> Pure functions are obviously important to the semantics of this approach.  
>> We can get by without compiler verification, using documentation just as we 
>> do for protocol requirements that can't be verified.  That said, it would be 
>> pretty disappointing to have to avoid using actors in the implementation 
>> simply because we can't move pure functions from one actor to another as 
>> necessary.
>> 
>> To be clear, I am talking in the context of "the fullness of time".  It 
>> would be perfectly acceptable to ship actors before pure functions.  That 
>> said, I do think it's crucial that we eventually have the ability to verify 
>> pure functions and move them around at will.
> 
> Right.  Pure functions are also nice when you care about thread safety, and 
> there is a lot of work on this.  C has __attribute__((const)) and ((pure)) 
> for example, c++ has constexpr, and many research languages have built full 
> blown effects systems.
> 
> My principle concern is that things like this quickly become infectious: LOTS 
> of things are pure functions, and requiring them all to be marked as such 
> becomes a lot of boilerplate and conceptual overhead.  This is happening in 
> the C++ community with constexpr for example.

At a rough guess, how many of the stdlib's functions could realistically have 
their purity inferred?

If we define our semantics carefully enough, could we realistically make it so 
that "@pure" or "@impure" (or whatever) would simply be a note to the compiler, 
letting it skip that bit of analysis for the function in question?



> The secondary concern is that you need to build out the model enough that you 
> don’t prevent abstractions.  A pure function should be able to create an 
> instance of a struct, mutate it (i.e. calling non-pure functions) etc.  This 
> requires a non-trivial design, and as the design complexity creeps, you run 
> the risk of it getting out of control.

Did we ever get around to figuring which definition(s) of "pure" that we wanted 
to support, or did the discussion always get out of scope before we got that 
far? I know the issue's been brought up, but I don't recall if it was discussed 
enough to reach any conclusions.

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

Re: [swift-evolution] Enums and Source Compatibility

[David Sweeris via swift-evolution]

> On Aug 9, 2017, at 11:04, Matthew Johnson <matt...@anandabits.com> wrote:
> 
>> On Aug 9, 2017, at 12:15 PM, Tony Allevato via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>>> On Wed, Aug 9, 2017 at 9:40 AM David Sweeris via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> (Now with more mailing lists in the "to" field!)
>>>> On Aug 8, 2017, at 3:27 PM, Jordan Rose via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>> Hi, everyone. Now that Swift 5 is starting up, I'd like to circle back to 
>>>> an issue that's been around for a while: the source compatibility of 
>>>> enums. Today, it's an error to switch over an enum without handling all 
>>>> the cases, but this breaks down in a number of ways:
>>>> 
>>>> - A C enum may have "private cases" that aren't defined inside the 
>>>> original enum declaration, and there's no way to detect these in a switch 
>>>> without dropping down to the rawValue.
>>>> - For the same reason, the compiler-synthesized 'init(rawValue:)' on an 
>>>> imported enum never produces 'nil', because who knows how anyone's using C 
>>>> enums anyway?
>>>> - Adding a new case to a Swift enum in a library breaks any client code 
>>>> that was trying to switch over it.
>>>> 
>>>> (This list might sound familiar, and that's because it's from a message of 
>>>> mine on a thread started by Matthew Johnson back in February called 
>>>> "[Pitch] consistent public access modifiers". Most of the rest of this 
>>>> email is going to go the same way, because we still need to make progress 
>>>> here.)
>>>> 
>>>> At the same time, we really like our exhaustive switches, especially over 
>>>> enums we define ourselves. And there's a performance side to this whole 
>>>> thing too; if all cases of an enum are known, it can be passed around much 
>>>> more efficiently than if it might suddenly grow a new case containing a 
>>>> struct with 5000 Strings in it.
>>>> 
>>>> 
>>>> Behavior
>>>> 
>>>> I think there's certain behavior that is probably not terribly 
>>>> controversial:
>>>> 
>>>> - When enums are imported from Apple frameworks, they should always 
>>>> require a default case, except for a few exceptions like NSRectEdge. (It's 
>>>> Apple's job to handle this and get it right, but if we get it wrong with 
>>>> an imported enum there's still the workaround of dropping down to the raw 
>>>> value.)
>>>> - When I define Swift enums in the current framework, there's obviously no 
>>>> compatibility issues; we should allow exhaustive switches.
>>>> 
>>>> Everything else falls somewhere in the middle, both for enums defined in 
>>>> Objective-C:
>>>> 
>>>> - If I define an Objective-C enum in the current framework, should it 
>>>> allow exhaustive switching, because there are no compatibility issues, or 
>>>> not, because there could still be private cases defined in a .m file?
>>>> - If there's an Objective-C enum in another framework (that I built 
>>>> locally with Xcode, Carthage, CocoaPods, SwiftPM, etc.), should it allow 
>>>> exhaustive switching, because there are no binary compatibility issues, or 
>>>> not, because there may be source compatibility issues? We'd really like 
>>>> adding a new enum case to not be a breaking change even at the source 
>>>> level.
>>>> - If there's an Objective-C enum coming in through a bridging header, 
>>>> should it allow exhaustive switching, because I might have defined it 
>>>> myself, or not, because it might be non-modular content I've used the 
>>>> bridging header to import?
>>>> 
>>>> And in Swift:
>>>> 
>>>> - If there's a Swift enum in another framework I built locally, should it 
>>>> allow exhaustive switching, because there are no binary compatibility 
>>>> issues, or not, because there may be source compatibility issues? Again, 
>>>> we'd really like adding a new enum case to not be a breaking change even 
>>>> at the source level.
>>>> 
>>>> Let's now flip this to the other side of the equation. I've been talking 
>>>> about us disallowing exhaustive switching, i.e. &q

Re: [swift-evolution] Enums and Source Compatibility

[David Sweeris via swift-evolution]

(Now with more mailing lists in the "to" field!)
> On Aug 8, 2017, at 3:27 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> Hi, everyone. Now that Swift 5 is starting up, I'd like to circle back to an 
> issue that's been around for a while: the source compatibility of enums. 
> Today, it's an error to switch over an enum without handling all the cases, 
> but this breaks down in a number of ways:
> 
> - A C enum may have "private cases" that aren't defined inside the original 
> enum declaration, and there's no way to detect these in a switch without 
> dropping down to the rawValue.
> - For the same reason, the compiler-synthesized 'init(rawValue:)' on an 
> imported enum never produces 'nil', because who knows how anyone's using C 
> enums anyway?
> - Adding a new case to a Swift enum in a library breaks any client code that 
> was trying to switch over it.
> 
> (This list might sound familiar, and that's because it's from a message of 
> mine on a thread started by Matthew Johnson back in February called "[Pitch] 
> consistent public access modifiers". Most of the rest of this email is going 
> to go the same way, because we still need to make progress here.)
> 
> At the same time, we really like our exhaustive switches, especially over 
> enums we define ourselves. And there's a performance side to this whole thing 
> too; if all cases of an enum are known, it can be passed around much more 
> efficiently than if it might suddenly grow a new case containing a struct 
> with 5000 Strings in it.
> 
> 
> Behavior
> 
> I think there's certain behavior that is probably not terribly controversial:
> 
> - When enums are imported from Apple frameworks, they should always require a 
> default case, except for a few exceptions like NSRectEdge. (It's Apple's job 
> to handle this and get it right, but if we get it wrong with an imported enum 
> there's still the workaround of dropping down to the raw value.)
> - When I define Swift enums in the current framework, there's obviously no 
> compatibility issues; we should allow exhaustive switches.
> 
> Everything else falls somewhere in the middle, both for enums defined in 
> Objective-C:
> 
> - If I define an Objective-C enum in the current framework, should it allow 
> exhaustive switching, because there are no compatibility issues, or not, 
> because there could still be private cases defined in a .m file?
> - If there's an Objective-C enum in another framework (that I built locally 
> with Xcode, Carthage, CocoaPods, SwiftPM, etc.), should it allow exhaustive 
> switching, because there are no binary compatibility issues, or not, because 
> there may be source compatibility issues? We'd really like adding a new enum 
> case to not be a breaking change even at the source level.
> - If there's an Objective-C enum coming in through a bridging header, should 
> it allow exhaustive switching, because I might have defined it myself, or 
> not, because it might be non-modular content I've used the bridging header to 
> import?
> 
> And in Swift:
> 
> - If there's a Swift enum in another framework I built locally, should it 
> allow exhaustive switching, because there are no binary compatibility issues, 
> or not, because there may be source compatibility issues? Again, we'd really 
> like adding a new enum case to not be a breaking change even at the source 
> level.
> 
> Let's now flip this to the other side of the equation. I've been talking 
> about us disallowing exhaustive switching, i.e. "if the enum might grow new 
> cases you must have a 'default' in a switch". In previous (in-person) 
> discussions about this feature, it's been pointed out that the code in an 
> otherwise-fully-covered switch is, by definition, unreachable, and therefore 
> untestable. This also isn't a desirable situation to be in, but it's 
> mitigated somewhat by the fact that there probably aren't many framework 
> enums you should exhaustively switch over anyway. (Think about Apple's 
> frameworks again.) I don't have a great answer, though.
> 
> For people who like exhaustive switches, we thought about adding a new kind 
> of 'default'—let's call it 'unknownCase' just to be able to talk about it. 
> This lets you get warnings when you update to a new SDK, but is even more 
> likely to be untested code. We didn't think this was worth the complexity.
> 
> 
> Terminology
> 
> The "Library Evolution" doc (mostly written by me) originally called these 
> "open" and "closed" enums ("requires a default" and "allows exhaustive 
> switching", respectively), but this predated the use of 'open' to describe 
> classes and class members. Matthew's original thread did suggest using 'open' 
> for enums as well, but I argued against that, for a few reasons:
> 
> - For classes, "open" and "non-open" restrict what the client can do. For 
> enums, it's more about providing the client with additional guarantees—and 
> "non-open" is the one with more guarantees.
> - The 

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

[David Sweeris via swift-evolution]

> On Aug 8, 2017, at 06:38, Karl Wagner <razie...@gmail.com> wrote:
> 
> 
>>> On 8. Aug 2017, at 04:35, David Sweeris via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> 
>>> On Aug 7, 2017, at 3:00 PM, Logan Shire via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> One of my longstanding frustrations with generic types and protocols has 
>>> been how hard it is to work with them when their type is unspecified.
>>> Often I find myself wishing that I could write a function that takes a 
>>> generic type or protocol as a parameter, but doesn’t care what its generic 
>>> type is.
>>> 
>>> For example, if I have a type:
>>> 
>>> struct Foo {
>>> let name: String
>>> let value: T
>>> }
>>> 
>>> or:
>>> 
>>> protocol Foo {
>>> associatedtype T
>>> var name: String { get }
>>> var value: T { get }
>>> }
>>> 
>>> And I want to write a function that only cares about Foo.name, I’d like to 
>>> be able to:
>>> 
>>> func sayHi(to foo: Foo) {
>>> print("hi \(foo.name)")
>>> }
>>> 
>>> But instead I get the error, “Reference to generic type Foo requires 
>>> arguments in <…>”
>>> 
>>> Also, when you want to have a polymorphic array of generic types, you can’t:
>>> 
>>> let foos: [Foo] = [Foo(name: "Int", value: 2), Foo(name: "Double", value: 
>>> 2.0)]
>>> 
>>> And if you remove the explicit type coercion, you just get [Any]
>>> 
>>> let foos = [Foo(name: "Int", value: 2), Foo(name: "Double", value: 2.0)]
>>> 
>>> I wish that could be inferred to be [Foo].
>> 
>> What happens if you try to say "foos: [Foo] = ..."? 
>> 
> 
> Foo and Foo are very different. Otherwise, you could take a 
> Foo, cast it to a Foo and set a String as its value.
> 
> I think what he means are partial generics, e.g: Foo<_>.

Oh I know, I just couldn't remember if it'd work as long as you didn't mess 
with the generic bits.

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

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

[David Sweeris via swift-evolution]

> On Aug 7, 2017, at 3:00 PM, Logan Shire via swift-evolution 
>  wrote:
> 
> One of my longstanding frustrations with generic types and protocols has been 
> how hard it is to work with them when their type is unspecified.
> Often I find myself wishing that I could write a function that takes a 
> generic type or protocol as a parameter, but doesn’t care what its generic 
> type is.
> 
> For example, if I have a type:
> 
> struct Foo {
> let name: String
> let value: T
> }
> 
> or:
> 
> protocol Foo {
> associatedtype T
> var name: String { get }
> var value: T { get }
> }
> 
> And I want to write a function that only cares about Foo.name, I’d like to be 
> able to:
> 
> func sayHi(to foo: Foo) {
> print("hi \(foo.name)")
> }
> 
> But instead I get the error, “Reference to generic type Foo requires 
> arguments in <…>”
> 
> Also, when you want to have a polymorphic array of generic types, you can’t:
> 
> let foos: [Foo] = [Foo(name: "Int", value: 2), Foo(name: "Double", value: 
> 2.0)]
> 
> And if you remove the explicit type coercion, you just get [Any]
> 
> let foos = [Foo(name: "Int", value: 2), Foo(name: "Double", value: 2.0)]
> 
> I wish that could be inferred to be [Foo].

What happens if you try to say "foos: [Foo] = ..."? 



> I’d like to propose being able to use the non-generic interface of a type 
> normally. 
> I.e. if you have a type Foo, it is implicitly of type Foo as well. The 
> type Foo could be used like any other type.
> It could be a parameter in a function, a variable, or even the generic type 
> of another type (like a Dictionary)
> 
> The only restriction is that if you want to call or access, directly or 
> indirectly, a function or member that requires the generic type,
> the generic type would have to be known at that point.
> 
> Foo should be able to be implicitly casted to Foo wherever you want, and 
> Foo could be cast to Foo conditionally.
> Initializers would still obviously have to know the generic type, but given 
> the above example, you should be able to:
> 
> let names = foos.map { $0.name }
> 
> However, you could not do the following:
> 
> let foos = [Foo]()
> 
> Because the initializer would need to know the generic type in order to 
> allocate the memory.
> 
> Let me know what you think!


The idiomatic solution would be to create a `Named` protocol with a `var name: 
String {get}` property, and write your function like `func sayHi(to foo:Named) 
{...}`. However, this `Named`protocol is really pretty trivial -- its purpose 
is simply to "degenericify" a generic type, not to provide any semantic 
meaning. Perhaps an analogy could be drawn between such "trivial protocols" and 
how we sometimes view tuples as "trivial structs"? Dunno, maybe I'm just trying 
to turn two trees into a forest, but this kinda smells like it might be part of 
a bigger issue, and if it is I'd rather tackle that and then see if we still 
need to address anything here.

+1, either way, though.

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

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[David Sweeris via swift-evolution]

> On Aug 2, 2017, at 21:45, Daryle Walker via swift-evolution 
>  wrote:
> 
> I’m not good at explicit explanations, so having to justify adding a type 
> that’s been around for a long time (at least FORTRAN 4+ decades ago) an 
> almost every systems programming language has is frustrating. I thought the 
> desire would be obvious; if there were FSAs in Swift 1, would there be any 
> “just slap Collection on tuples and be done with it” suggestions now? It 
> doesn’t help that I still don’t know why FSAs where skipped in Swift 1; did 
> they forget or was there some high-level type-theory reason? (Were the type 
> description records in the Swift ABI too fragile for a type that wouldn’t 
> have per-sub-object entries (assuming theoretical Swift-1-FSAs weren’t 
> translated to massive homogenous tuples)?)

This is purely a guess, but I think it was just that there's only so much time 
and there's not much that actually *requires* FSAs, other than to remove 
overhead.

Actually, as they've been described in this thread, I think that's all they do? 
The way we'd previously discussed them, they could conform to protocols and 
such, like any other type.

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

Re: [swift-evolution] [Pitch] #dup -- a duplication "macro"(?)

[David Sweeris via swift-evolution]

> On Aug 2, 2017, at 21:39, Daryle Walker  wrote:
> 
>>> On Aug 1, 2017, at 9:56 AM, Daryle Walker  wrote:
>>> 
 On Jul 31, 2017, at 10:38 PM, David Sweeris  wrote:
 
 On Jul 31, 2017, at 7:23 PM, Daryle Walker via swift-evolution 
  wrote:
 
 The tuple will be a bunch of “T,” but the count mechanically added depends 
 on compiler-visible number N. Well, since this is part of a proposal that 
 already mutates the language, I thought why not add a primitive operation 
 by fiat:
 
 func tuple(from: [N; T]) -> ( #dup(N; T) )
 
 where “#dup” dumps a comma-separated list repeating the right-side entity 
 with a multiplicity of the left-side value. The left-side value has to be 
 a compiler constant expression. I was going to have the right side be an 
 arbitrary token sequence, but I think it’s better for now to limit it to 
 either a type (or similar) or an expression. Obviously, the receiver has 
 to compatible with whatever being dumped there.
>>> 
>>> We've been talking about adding Variadic Generic Parameters for a while, 
>>> and I'm pretty sure that the functionality you're suggesting here would be 
>>> a subset of that. We're just waiting for it to come into scope.
>> 
>> I don’t think this functionality is covered by variadic generic parameters.
> 
> After a few hours, I figured out what was bugging me. Variadic generic 
> parameters, and the existing variadic function parameters, CONSUME 
> arbitrarily long comma-separated lists. The #dup facility PRODUCES those 
> kinds of lists. The features are duals, not the same. The features can 
> synergize.

Ah, ok, I see what you're saying now... I hadn't considered that the 
as-yet-hypothetical VGP proposal wouldn't allow for both consuming and 
producing VGP lists.

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

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[David Sweeris via swift-evolution]

> On Aug 2, 2017, at 4:29 PM, Nicolas Fezans  wrote:
> 
> Your notation is indeed correct, even though using x on both side might 
> confuse some people, this is correct. But no I would not go that far,

I would, just not right now. There are more important issues to the larger 
community that need to be addressed before we (it might just be me ) can start 
worrying about how to turn the equations from a math textbook into value swift 
code.

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

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[David Sweeris via swift-evolution]

> On Aug 2, 2017, at 4:29 PM, Xiaodi Wu  wrote:
> 
>> On Wed, Aug 2, 2017 at 6:17 PM, David Sweeris  wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> On Aug 2, 2017, at 3:43 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>>> 
 On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans  
 wrote:
 I think that the items mentioned earlier in the list (just reminded below) 
 should not all be treated equally.
 
 - RNG and cryptography library (CryptoSwift could be a good base for this)
 - Generic Math library/Vector library
 - Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList, 
 graphs, etc)
 - Modern DateTime library
 - Modern String processing toolkit
 - 2D Graphics library (similar to cairo)
 - Windowing/UI library
 
 By that I mean that I see at least one distinction to make between:
 
 a) the libraries that would make Swift and the programmer experience with 
 these libraries under Swift significantly better if they are (or at least 
 feel) deeply integrated in the language (for instance with associated 
 syntax / syntax sugar)
 and 
 b) those that would not really benefit from such an integration to the 
 language.
 
 For me a core math library, clearly belongs to category a)
 I am of course not talking about a syntax sugar to call a sin or cos 
 function, but rather to manipulate other objects such as N-dimensional 
 matrices, defining maths functions that can take such matrices as argument 
 e.g. sin(A) with A as matrix produces a matrix of the same size where all 
 elements are the sinus values of the elements of A (sorry but things like 
 this calling map() with 'sin' looks quite ugly for scientists).
 Such a good math syntax should be compact enough to have complete 
 equations looking "close enough" to the maths equations you could have 
 written in a LaTeX or Word documentation of your scientific code. IMO a 
 well integrated swift core math library should feel a Julia or Matlab code 
 (while still having the power of Swift in terms of speed and modern 
 programming paradigms) instead of looking and feeling like 'numpy'. But 
 the latter is what you get if you just make a math library with no 
 integration to the language syntax, operators, and basic functions.
>>> 
>>> I agree that if this would require compiler support, then it needs to be 
>>> part of the standard library. However, I don't see anything about what you 
>>> describe that cannot be supported as a third-party library.
>> 
>> Getting the syntax right could possibly require some compiler changes. 
>> Maybe. Depends on what "right" means. Declaring a variable, x, to be "the 
>> set of all real numbers such that x*sin(x) is an integer" using syntax like 
>> this, "let x = {x ∈ ℝ | x * sin(x) ∈ ℕ}", would be neat (I'm a bit hazy on 
>> my set notation... that might not actually be correct).
>> We're actually not that far off from that, compiler-wise, I mean. Aside 
>> defining the relevant types, operators, and identifiers, that exact syntax 
>> pretty much just requires the compiler to allow using a certain types of 
>> variables in their own declaration and either one heck of an 
>> `ExpressibleByClosureLiteral` protocol, or improvements to the type 
>> inference engine.
> 
> We must prioritize features that make the biggest impact for the general 
> community, however. Swift still lacks ABI stability, ownership, concurrency, 
> etc. In terms of math facilities, we still don't have a model for dealing 
> with floating point errors. And, yes, there are improvements to be made in 
> terms of having consistent special functions (sin, cos) in Swift (Glibc and 
> Darwin don't always give you the same answer). All of these things represent 
> sorely needed yet large undertakings; none of these require more syntax.

Oh, I know. I wasn't claiming that we need massive compiler changes right now 
or anything, just providing an example of a syntax that a hypothetical 
"CoreMath" type of library might want to support which can't currently be made 
into legal swift code. 

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

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[David Sweeris via swift-evolution]

Sent from my iPad
> On Aug 2, 2017, at 3:43 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
>> On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans  wrote:
>> I think that the items mentioned earlier in the list (just reminded below) 
>> should not all be treated equally.
>> 
>> - RNG and cryptography library (CryptoSwift could be a good base for this)
>> - Generic Math library/Vector library
>> - Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList, graphs, 
>> etc)
>> - Modern DateTime library
>> - Modern String processing toolkit
>> - 2D Graphics library (similar to cairo)
>> - Windowing/UI library
>> 
>> By that I mean that I see at least one distinction to make between:
>> 
>> a) the libraries that would make Swift and the programmer experience with 
>> these libraries under Swift significantly better if they are (or at least 
>> feel) deeply integrated in the language (for instance with associated syntax 
>> / syntax sugar)
>> and 
>> b) those that would not really benefit from such an integration to the 
>> language.
>> 
>> For me a core math library, clearly belongs to category a)
>> I am of course not talking about a syntax sugar to call a sin or cos 
>> function, but rather to manipulate other objects such as N-dimensional 
>> matrices, defining maths functions that can take such matrices as argument 
>> e.g. sin(A) with A as matrix produces a matrix of the same size where all 
>> elements are the sinus values of the elements of A (sorry but things like 
>> this calling map() with 'sin' looks quite ugly for scientists).
>> Such a good math syntax should be compact enough to have complete equations 
>> looking "close enough" to the maths equations you could have written in a 
>> LaTeX or Word documentation of your scientific code. IMO a well integrated 
>> swift core math library should feel a Julia or Matlab code (while still 
>> having the power of Swift in terms of speed and modern programming 
>> paradigms) instead of looking and feeling like 'numpy'. But the latter is 
>> what you get if you just make a math library with no integration to the 
>> language syntax, operators, and basic functions.
> 
> I agree that if this would require compiler support, then it needs to be part 
> of the standard library. However, I don't see anything about what you 
> describe that cannot be supported as a third-party library.

Getting the syntax right could possibly require some compiler changes. Maybe. 
Depends on what "right" means. Declaring a variable, x, to be "the set of all 
real numbers such that x*sin(x) is an integer" using syntax like this, "let x = 
{x ∈ ℝ | x * sin(x) ∈ ℕ}", would be neat (I'm a bit hazy on my set notation... 
that might not actually be correct).
We're actually not that far off from that, compiler-wise, I mean. Aside 
defining the relevant types, operators, and identifiers, that exact syntax 
pretty much just requires the compiler to allow using a certain types of 
variables in their own declaration and either one heck of an 
`ExpressibleByClosureLiteral` protocol, or improvements to the type inference 
engine.

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

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[David Sweeris via swift-evolution]

> On Aug 1, 2017, at 10:54 AM, Daryle Walker via swift-evolution 
>  wrote:
> 
> A tuple can have its members initialized in piecemeal and still satisfy 
> deterministic initialization. The named types need to do all their 
> sub-objects' initializations before any designated initializer ends. I want 
> the former for array instances, not the latter. It’s important for numeric 
> applications, so math arrays don’t have to be set twice, once for an 
> arbitrary default and again for the real data.

Eh? What do you mean by "initialized in piecemeal"? These both give errors:
let x:(Int, Int) = (0) // something about not being able to convert `Int` to 
`(Int, Int)`
let x:(Int, Int) = (0, _) // something about "_" only being allowed in patterns

Is that what you're talking about?

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

Re: [swift-evolution] [Pitch] #dup -- a duplication "macro"(?)

[David Sweeris via swift-evolution]

> On Jul 31, 2017, at 7:23 PM, Daryle Walker via swift-evolution 
>  wrote:
> 
> When coming up with new array interfaces, I had some array to/from tuple 
> conversion functions:
> 
> func array(from: (T, …U)) -> [1 + #countOf(U) ; T] allwhere U == T
> 
> The problem is going the other way:
> 
> func tuple(from: [N; T]) -> ???
> 
> The tuple will be a bunch of “T,” but the count mechanically added depends on 
> compiler-visible number N. Well, since this is part of a proposal that 
> already mutates the language, I thought why not add a primitive operation by 
> fiat:
> 
> func tuple(from: [N; T]) -> ( #dup(N; T) )
> 
> where “#dup” dumps a comma-separated list repeating the right-side entity 
> with a multiplicity of the left-side value. The left-side value has to be a 
> compiler constant expression. I was going to have the right side be an 
> arbitrary token sequence, but I think it’s better for now to limit it to 
> either a type (or similar) or an expression. Obviously, the receiver has to 
> compatible with whatever being dumped there.
> 
> …
> 
> Could we do better than simple repetition? What if we define a “$$n” unit, 
> where “n” is a nonnegative integer. For each comma-separated item, the unit 
> will be replaced by increasing compiler-constant integers from zero. If using 
> an expression, maybe you can call a function on the double-dollar value to 
> get your own custom values there. This can be expanded to types once 
> value-based generic parameters get added.
> 
> When there are nested #dup calls, the double-dollar unit refers to the 
> counter for the innermost #dup. Maybe there can be a triple-dollar unit for 
> the immediately enclosing #dup. Even quadruple- or more-dollar units for the 
> outer levels. (Hopefully, nothing more that one level would be needed.)
> 
> …
> 
> Later, I remembered the "( 6 * TupleMemberType )” syntax for repeating a type 
> within a tuple that's sometimes suggested. The #dup facility can be seen as a 
> generalized version of that quasi-array-specific idea.

We've been talking about adding Variadic Generic Parameters for a while, and 
I'm pretty sure that the functionality you're suggesting here would be a subset 
of that. We're just waiting for it to come into scope.

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

Re: [swift-evolution] Extensions

[David Sweeris via swift-evolution]

> On Jul 31, 2017, at 4:19 PM, Omar Charif via swift-evolution 
>  wrote:
> 
> I am a big fan of extensions, but I wonder what would happen years from now 
> when we start to have lots of extensions created for the primitive classes. 
> The problem is that we can write a String extension for example in any swift 
> file in the project, the name of the file has nothing to do with the content 
> of it. But for extensions … I think it is more ordered if we can see all Int 
> extensions for example in same file. I don’t know how this could be done, 
> maybe there is a way to even copy paste it automatically in a single file but 
> for easier access I guess it would be nice to be able to find all extensions 
> of a class in one place. You might not restrict it for anyone to write it in 
> that single file, but you could automatically create a file for each class 
> just to group all extensions of a class. Is that possible ?

I don't know how hard that'd be, but it sounds like a really neat feature for 
that new layer that Xcode's using to integrate with the compiler!

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

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

[David Sweeris via swift-evolution]

On Jul 31, 2017, at 12:15 AM, Gor Gyolchanyan via swift-evolution 
 wrote:

>> On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution 
>>  wrote:
>> 
>>> On Jul 30, 2017, at 11:43 PM, Daryle Walker  wrote:
>>> The parameters for a fixed-size array type determine the type's 
>>> size/stride, so how could the bounds not be needed during compile-time? The 
>>> compiler can't layout objects otherwise. 
>> 
>> Swift is not C; it is perfectly capable of laying out objects at run time.  
>> It already has to do that for generic types and types with resilient 
>> members.  That does, of course, have performance consequences, and those 
>> performance consequences might be unacceptable to you; but the fact that we 
>> can handle it means that we don't ultimately require a semantic concept of a 
>> constant expression, except inasmuch as we want to allow users to explicitly 
>> request guarantees about static layout.
> 
> Doesn't this defeat the purpose of generic value parameters? We might as well 
> use a regular parameter if there's no compile-time evaluation involved. In 
> that case, fixed-sized arrays will be useless, because they'll be normal 
> arrays with resizing disabled. As far as I know, the pinnacle of uses for 
> fixed-size arrays is having a compile-time pre-allocated space of the 
> necessary size (either literally at compile-time if that's a static variable, 
> or added to the pre-computed offset of the stack pointer in case of a local 
> variable).

Not at all... it'd let us use non-type parameters to affect a value's type... 
The classic example (or at least the one that I keep typing out whenever the 
topic comes up) is vector matrix math:
func *  (lhs: Matrix, 
rhs: Matrix) -> Matrix {
// no need to check if the dimensions at runtime because the type system 
turned dimension mismatches into a compile-time error
...
}

Sticking with the math theme, if you can make the variable's name (that is, 
your package's variable type, not a Swift var or let) part of its type, I 
suspect there's a trick you could do in a symbolic manipulation library 
involving simplifying equations (but I haven't thought it through enough to say 
for sure).

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

Re: [swift-evolution] [Idea] Custom keywords for operators.

[David Sweeris via swift-evolution]

Sent from my iPad
> On Jul 31, 2017, at 2:09 PM, Gor Gyolchanyan via swift-evolution 
>  wrote:
> 
> So I was thinking the other day (and by "the other day" I mean "It just 
> occurred to me") that Swift's custom operator declaration mechanism is pretty 
> sweet (it's become even sweeter ever since numeric precedence values were 
> replaced with purely relativistic precedence trees). There are currently only 
> two problems with them that grind my operator-declaring endeavors to a 
> painful halt:
>   1. The fact that most punctuation characters on the keyboard (think - 
> ASCII) are reserved, so any custom operator either has to be a long sequence 
> of two or three non-reserved ASCII characters or have to include 
> difficult-to-type unicode punctuation characters.
>   2. The fact that anything that passes as an identifier character (which 
> includes a surprisingly wide array of punctuation characters) is off the 
> table as well.
> 
> I have no good idea how to deal with the first problem

Unicode has a lot of operator characters. If the one you want isn't already 
easy to type, you can use a utility like Ukelele 
(http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi=ukelele) to map 
them to some unused key combination (on macOS, anyway... dunno what the 
Linux/Windows equivalent is).



> but the second problem seems to have a bafflingly simple solution that I 
> can't believe I haven't noticed until now.
> And the reason to even try to solve that problem is because Swift already has 
> a lot of operators with identifiers in them:
>   * infix is
>   * infix as
>   * infix as?
>   * infix as!
>   * prefix try
>   * prefix try?
>   * prefix try!
>   * prefix throw
> So this is hardly a new concept to Schwifty developers.
> 
> The way I think could this could be solved is by introducing custom keywords 
> that can be defined just like custom operators can be.
> The custom keyword has to be a valid identifier and is defined much like a 
> non-infix custom operator (by writing `keyword`, followed by an identifier).
> 
> Custom operator definitios would now be permitted to have any number of 
> non-adjacent keywords among usual punctuation characters.
> Any identifier that matches a custom keyword has to be escaped with backticks 
> just like it's the case for regular keywords.
> Prefix operators may not end with a keyword.
> Postfix operators may not begin with a keyword.
> Infix operators that either begin or end with a keyword may not be used 
> without whitespaces.

I wouldn't be opposed to just requiring whitespace around infix operators in 
general (but I suspect I'm in the minority on that).

> Here's an example:
> 
> precedencegroup AggregateFormingPrecedence {
>   higherThan: TernaryPrecedence
>   lowerThan: LogicalDisjunctionPrecedence
> }
> 
> precedencegroup DimensionFormingPrecedence {
>   higherThan: AggregateFormingPrecedence
>   lowerThan: LogicalDisjunctionPrecedence
> }
> 
> keyword of
> keyword by
> infix operator of: AggregateFormingPrecedence
> infix operator by: DimensionFormingPrecedence
> 
> public struct Matrix where Element: FloatingPoint {
> 
>   public struct Dimensions {
>   let rows: Int
>   let columns: Int
>   }
> 
>   public init(dimensions: Dimensions, value: Element) {
>   self.elements = .init(repeating: value, count: dimensions.rows 
> * dimensions.columns)
>   }
> 
>   private var elements: [Element]
>   
> }
> 
> public static func by(_ rows: Int, _ columns: Int) -> Matrix.Dimensions {
>   return .init(rows: rows, columns: columns)
> }
> 
> public static func of(_ dimensions: Matrix.Dimensions, _ value: 
> Element) -> Matrix where Element: FloatingPoint {
>   return .init(dimensions: dimensions, value: value)
> }
> 
> let m = 3 by 4 of 1.0 // m is of type Matrix
> 
> I feel like these kind of changes would be best considered in the early 
> stages of a major release (namely, Swift 5) so that they have time to be 
> refined and tested.
> What do you guys think?

The topic of using identifiers as operators has come up before, and rejected on 
the grounds that it'd make parsing things much slower. I don't recall if your 
ideas regarding restrictions on the spellings have been discussed, though.

I'm +1 if the technical issues can be sorted out.

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

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

[David Sweeris via swift-evolution]

> On Jul 31, 2017, at 1:37 PM, Gor Gyolchanyan via swift-evolution 
>  wrote:
> 
> 
>>> On Jul 31, 2017, at 11:23 PM, John McCall  wrote:
>>> 
>>> 
 On Jul 31, 2017, at 4:00 PM, Gor Gyolchanyan 
  wrote:
 
 
> On Jul 31, 2017, at 10:09 PM, John McCall  wrote:
> 
>> On Jul 31, 2017, at 3:15 AM, Gor Gyolchanyan 
>>  wrote:
>>> On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution 
>>>  wrote:
>>> 
>>> On Jul 30, 2017, at 11:43 PM, Daryle Walker  wrote:
>>> The parameters for a fixed-size array type determine the type's 
>>> size/stride, so how could the bounds not be needed during compile-time? 
>>> The compiler can't layout objects otherwise. 
>> 
>> Swift is not C; it is perfectly capable of laying out objects at run 
>> time.  It already has to do that for generic types and types with 
>> resilient members.  That does, of course, have performance consequences, 
>> and those performance consequences might be unacceptable to you; but the 
>> fact that we can handle it means that we don't ultimately require a 
>> semantic concept of a constant expression, except inasmuch as we want to 
>> allow users to explicitly request guarantees about static layout.
> 
> Doesn't this defeat the purpose of generic value parameters? We might as 
> well use a regular parameter if there's no compile-time evaluation 
> involved. In that case, fixed-sized arrays will be useless, because 
> they'll be normal arrays with resizing disabled.
 
 You're making huge leaps here.  The primary purpose of a fixed-size array 
 feature is to allow the array to be allocated "inline" in its context 
 instead of "out-of-line" using heap-allocated copy-on-write buffers.  
 There is no reason that that representation would not be supportable just 
 because the array's bound is not statically known; the only thing that 
 matters is whether the bound is consistent for all instances of the 
 container.
 
 That is, it would not be okay to have a type like:
  struct Widget {
let length: Int
var array: [length x Int]
  }
 because the value of the bound cannot be computed independently of a 
 specific value.
 
 But it is absolutely okay to have a type like:
  struct Widget {
var array: [(isRunningOnIOS15() ? 20 : 10) x Int]
  }
 It just means that the bound would get computed at runtime and, 
 presumably, cached.  The fact that this type's size isn't known statically 
 does mean that the compiler has to be more pessimistic, but its values 
 would still get allocated inline into their containers and even on the 
 stack, using pretty much the same techniques as C99 VLAs.
>>> 
>>> I see your point. Dynamically-sized in-place allocation is something that 
>>> completely escaped me when I was thinking of fixed-size arrays. I can say 
>>> with confidence that a large portion of private-class-copy-on-write value 
>>> types would greatly benefit from this and would finally be able to become 
>>> true value types.
>> 
>> To be clear, it's not obvious that using an inline array is always a good 
>> move for performance!  But it would be a tool available for use when people 
>> felt it was important.
> 
> That's why I'm trying to push for compile-time execution system. All these 
> problems (among many others) could be designed out of existence and the 
> compiler would be incredibly simple in the light of all the different 
> specific features that the community is asking for. But I do feel your urge 
> to avoid inventing a bulldozer factory just for digging a hole in a sandbox. 
> It doesn't have to be relied upon by the type checker or generic resolution 
> mechanism. It would be purely auxiliary.

FWIW, if we were having this conversation before maintaining source 
compatibility was such an important goal, I'd be far more willing to go along 
with just getting a feature implemented so that we can play now and tweak the 
design later. As it is, though — and even without that compatibility goal — 
realistically speaking, it'll be a year+ before anything major that we approve 
now is likely to make its way into an official toolchain. There's no need to 
rush the process, not until we near the end of the Swift 5 proposal timeframe.

Although I will give my +1 for having this discussion being declared in-scope 
for a Swift 5.


> But that would single-handedly move a large chunk of the compiler into stdlib 
> and a huge portion of various little incidental proposals would fade away 
> because they can now easily be implemented in Swift for specific purposes.

Getting rid of as much "compiler magic" as possible is one of Swift's goals. If 
soneobe though of a way 

Re: [swift-evolution] Why couldn't a class call any of its superclass' initializers?

[David Sweeris via swift-evolution]

I think it's some subtlety... I might vaguely remember someone saying something 
about it. Since a proposal didn't come of that, I'm assuming there was a 
technical issue or something. I could easily be wrong, though.

- Dave Sweeris

> On Jul 25, 2017, at 9:36 PM, Daryle Walker via swift-evolution 
>  wrote:
> 
> [Sorry if this's been discussed before.]
> 
> As long as the superclass sub-object gets initialized, it shouldn't matter if 
> the initializer was designated or convenience. Is there some subtle step on 
> the two-phase initialization I'm missing? Or is this a point to extend in a 
> future version of Swift?
> 
> Sent from my iPhone
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Small bit of sugar for enum case with Void associated value

[David Sweeris via swift-evolution]

> On Jul 25, 2017, at 2:20 PM, Xiaodi Wu  wrote:
> 
> Yes, I discussed this some time back. It breaks some things with overloads, 
> if I recall, but off the top of my head not recalling what.

Functions that are overloaded with one version taking no arguments and another 
taking only some number of Void arguments would break, but I'm not sure how 
important that is. Nor am I sure that's all that would break. I'm mean, really 
we'd just be automatically adding functions that only have Void arguments to 
the call-site "func foo() {}" vs "func foo(x: SomeType = someValue) {}" issue.

Meh, maybe such implicit behavior should be reserved for "Never", if we ever 
get that.

- Dave Sweeris

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

Re: [swift-evolution] [Pitch] Small bit of sugar for enum case with Void associated value

[David Sweeris via swift-evolution]

> On Jul 25, 2017, at 12:38, Robert Bennett via swift-evolution 
>  wrote:
> 
> Currently if you have the following enum:
> 
> enum E {
>   case c(T)
> }
> 
> then if T is Void, you have to write one of the following:
> 
> let x: E = .c(Void())
> let y: E = .c(())
> 
> Looks awkward, no? In this case you can omit `` after `E` because it 
> can be inferred, but if writing a (non-generic) function taking an argument 
> of type `E`, then the `` cannot be omitted, and you still have to 
> write `.c(())` for the case name.
> 
> I’m proposing that for enum cases with a single associated value of Void 
> type, or of a generic type that is equal to Void in some instance, you may 
> omit the parentheses altogether and merely write
> 
> let x: E = .c
> 
> The rationale is twofold: first, double parentheses just looks bad; second, 
> there is only a single value of type Void, which means the associated value 
> of `.c` is trivially inferable, and hence should be omissible.
> 
> I am not proposing that a bare `E.c` imply a type of `E` — `E.c` should 
> still be illegal in the absence of specification of the generic type — only 
> that when the type is known to be `E`, `.c` can replace `.c(())`.
> 
> Thoughts?

My first response is +1

My second response is to ask just how much would it break things to expand this 
and allow omitting the argument anywhere its type is known to be Void? Maybe by 
implicitly providing a default value of `()` wherever there's a `Void` 
argument? Like make `func foo(x: Void) {...}` implicitly become `func foo(x: 
Void = ()) {...}`? I have a sneaking suspicion that this question's already 
been asked, but I'm not sure.

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

Re: [swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

[David Sweeris via swift-evolution]

> On Jul 24, 2017, at 9:37 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jul 23, 2017, at 4:27 PM, Félix Cloutier  wrote:
>> 
 
 Well, fixed-size arrays don’t have initializers, for the same reason 
 tuples don’t: they’re compound types instead of named types and they 
 literally have nowhere to place initializer definitions. But like tuples, 
 FSAs have a literal syntax that works as a substitute for full-blown 
 initializers.
>>> 
>>> Ok, sure.  They aren’t literally initializers in the stdlib (they are built 
>>> into the compiler), but they have initialization semantics and can be 
>>> spelled in whatever way makes ergonomic sense.  Keeping them aligned with 
>>> Array seems like a good starting point.
>> 
>> Either way, in the context of fixed-size arrays, I think that it's a broader 
>> problem that anonymous types can't have anything attached to them. This also 
>> prevents fixed-size arrays from conforming to protocols, even Sequence, and 
>> Swift would need variadic generics or (possibly, depending on the syntax) 
>> non-type generic parameters to even create a wrapper.
> 
> Agreed. However, solving that general problem is hard, and completely 
> orthogonal to the win of having fixed sized arrays work.

Is there really any doubt that we'll eventually get Variadic Generics and 
Non-Type Generic Parameters? They're always well-received whenever they come 
up, but they keep getting ruled out-of-scope before a proposal can be fully 
fleshed-out. I'm asking because it'd make it way easier to design a FSA 
proposal knowing that it could rely on those features. Personally, I'd even be 
ok with accepting such a proposal "pending the acceptance of its 'dependency 
proposals'" (with probably a quick re-review to make sure any subsequent 
proposals haven't materially changed how it'd work).

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

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[David Sweeris via swift-evolution]

> On Jul 24, 2017, at 9:22 AM, Félix Cloutier  wrote:
> 
> There are other alternatives that don't use generics. Last time this came 
> around, the straw man syntax was (4 x Int), and it was merely to be a 
> shorthand for (Int, Int, Int, Int).
> 
> Every non-existing feature that needs to be implemented to make fixed-size 
> arrays work are a drag. I've said it before and I'll say it again: major 
> features that this proposal wants to rely on should be brought independently 
> and discussed on their own. There are real problems with monolithic proposals:
> 
> They couple independent features in an all-or-nothing basket
> They consume a huge amount of review and design energy
> They force sub-features to be viewed through the telescope aimed at the main 
> feature, and make it easier to miss problems or opportunities in the big 
> pictures
> 
> The last point is especially worrying to me because things like non-type 
> generic parameters are *much bigger* than fixed-size arrays. I think that 
> it's a priority inversion to discuss non-type generic parameters as a bullet 
> point of fixed-size arrays.

+ all the 1s

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

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[David Sweeris via swift-evolution]

Which brings us I think full circle back to using literal values as generic 
parameters, "let fsa = FSA(whateverArgs) //where `Count` is an 
integer literal, or some other integer value that can be determined at compile 
time".

- Dave Sweeris

> On Jul 24, 2017, at 1:05 AM, Félix Cloutier via swift-evolution 
>  wrote:
> 
> It is not good enough for C interop because a design where the element count 
> is data rather than part of the type cannot be layout-compatible with a C 
> fixed-size array.
> 
> Félix
> 
>> Le 23 juil. 2017 à 22:22, Charles Srstka via swift-evolution 
>>  a écrit :
>> 
>> Do FSAs really need special sugar, though? They won’t be an extremely 
>> heavily-used construct, but rather they’ll be occasionally used either for 
>> performance reasons or to interact with C APIs. Sure, C had a short syntax 
>> for making them, but making pointers in C was short, too, and that hasn’t 
>> been carried over into Swift. In fact, a FSA has a lot in common with an 
>> UnsafeBufferPointer that you don’t have to worry about deallocating. 
>> Furthermore, there are collection types such as Set and ContiguousArray 
>> which are arguably more useful than FSA, yet don’t have their own syntax.
>> 
>> Is this really not good enough?
>> 
>> let arr = FixedArray(capacity: x)
>> 
>> Charles
>> 
>>> On Jul 23, 2017, at 11:03 PM, Taylor Swift via swift-evolution 
>>>  wrote:
>>> 
>>> This proposal gives FSAs their own literal syntax. You write [; 3, 5] to 
>>> make a FSA, not [3, 5].
>>> 
 On Sun, Jul 23, 2017 at 11:54 PM, David Sweeris  
 wrote:
 
> On Jul 23, 2017, at 8:32 PM, Taylor Swift  wrote:
> 
>> On Sun, Jul 23, 2017 at 5:48 PM, David Sweeris  
>> wrote:
>> 
>>> On Jul 23, 2017, at 12:18, Taylor Swift  wrote:
>>> 
 On Sun, Jul 23, 2017 at 2:21 PM, David Sweeris  
 wrote:
 
> On Jul 23, 2017, at 09:08, Taylor Swift  wrote:
> 
 
> let fsa:[2 * Int] = [2 * 5, 3] // [10, 3] ???
 
 Correct. If you wanted a multidimensional array, that'd be written 
 "let nestedFSA: [2*[5*Int]]". Or, speculating a bit, I suppose maybe 
 "let nestedFSA: [[5*Int]*2]", if we wanted there to be a column-major 
 option. IMHO all those read better than this proposal's syntax.
 
 
>>> 
>>> No, what I’m saying is does the phrase “[2 * 5, 3]” mean a fixed size 
>>> array of length two and with the elements 5 and 3, or a flexible sized 
>>> array with two elements 10 and 3? This is v confusing and difficult to 
>>> read, especially when you have actual multiplications going on such as 
>>> 
>>> let fsa:[2 * Int] = [2 * 3 * 5, 3] // [15, 3] ???
>> 
>> That's... huh? To me, "[2 * 3 * 5, 3]" should obviously evaluate to 
>> "[30, 3]". How are you getting that "[2*5*3, 3]" could be a 2-element 
>> FSA containing 15 and 3? Are you suggesting that instead of "[value * 
>> value * value, value]", it could be parsed as "[modifier value * value, 
>> value]" (with `modifier` being "2 *")? To me, that syntax would strongly 
>> suggest that the modifier only applies to the first element of the 
>> array, which would mean the only other option for parsing it would be 
>> equivalent to "[[3, 5], 3]", which is neither a match for fsa's type, 
>> nor a semantically valid array (the elements have to be the same type), 
>> nor a syntactically valid array (the nested array in the first element 
>> is missing its "[]").
>> 
> 
> Well, that is the syntax you’re proposing right? What comes on the left 
> of the asterisk is the FSA dimensions, and what comes to the right is the 
> FSA elements. 
 
 No, the type of the FSA's elements is what comes to the right: "[count * 
 Type]". I don't recall any discussion around the value side of things, so 
 I'd guess they would've just used the existing array literal syntax, "let 
 fsa: [2*[2*Int]] = [[0, 1], [2, 3]]".
 
 - Dave Sweeris
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[David Sweeris via swift-evolution]

> On Jul 23, 2017, at 8:32 PM, Taylor Swift  wrote:
> 
>> On Sun, Jul 23, 2017 at 5:48 PM, David Sweeris  wrote:
>> 
>>> On Jul 23, 2017, at 12:18, Taylor Swift  wrote:
>>> 
 On Sun, Jul 23, 2017 at 2:21 PM, David Sweeris  wrote:
 
> On Jul 23, 2017, at 09:08, Taylor Swift  wrote:
> 
 
> let fsa:[2 * Int] = [2 * 5, 3] // [10, 3] ???
 
 Correct. If you wanted a multidimensional array, that'd be written "let 
 nestedFSA: [2*[5*Int]]". Or, speculating a bit, I suppose maybe "let 
 nestedFSA: [[5*Int]*2]", if we wanted there to be a column-major option. 
 IMHO all those read better than this proposal's syntax.
 
 
>>> 
>>> No, what I’m saying is does the phrase “[2 * 5, 3]” mean a fixed size array 
>>> of length two and with the elements 5 and 3, or a flexible sized array with 
>>> two elements 10 and 3? This is v confusing and difficult to read, 
>>> especially when you have actual multiplications going on such as 
>>> 
>>> let fsa:[2 * Int] = [2 * 3 * 5, 3] // [15, 3] ???
>> 
>> That's... huh? To me, "[2 * 3 * 5, 3]" should obviously evaluate to "[30, 
>> 3]". How are you getting that "[2*5*3, 3]" could be a 2-element FSA 
>> containing 15 and 3? Are you suggesting that instead of "[value * value * 
>> value, value]", it could be parsed as "[modifier value * value, value]" 
>> (with `modifier` being "2 *")? To me, that syntax would strongly suggest 
>> that the modifier only applies to the first element of the array, which 
>> would mean the only other option for parsing it would be equivalent to "[[3, 
>> 5], 3]", which is neither a match for fsa's type, nor a semantically valid 
>> array (the elements have to be the same type), nor a syntactically valid 
>> array (the nested array in the first element is missing its "[]").
>> 
> 
> Well, that is the syntax you’re proposing right? What comes on the left of 
> the asterisk is the FSA dimensions, and what comes to the right is the FSA 
> elements. 

No, the type of the FSA's elements is what comes to the right: "[count * 
Type]". I don't recall any discussion around the value side of things, so I'd 
guess they would've just used the existing array literal syntax, "let fsa: 
[2*[2*Int]] = [[0, 1], [2, 3]]".

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

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[David Sweeris via swift-evolution]

> On Jul 23, 2017, at 2:49 PM, David Sweeris via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
> On Jul 23, 2017, at 12:18, Taylor Swift <kelvin1...@gmail.com 
> <mailto:kelvin1...@gmail.com>> wrote:
> 
>> Speaking of which, IIRC, at one point we were considering adding subscripts 
>> to tuples and using that for FSAs. I think the hangups were pretty much just 
>> that tuples can't conform to protocols and the iffy semantics of 
>> subscripting heterogeneous tuples. The former is a bit of a pain point 
>> anyway, and unless I've forgotten about some deal-breaker that was brought 
>> up in one of those threads, I think it's somewhat likely that we'll 
>> eventually do something about it. Unrelated to FSAs and subscripting tuples, 
>> we've also discussed variadic generic arguments... My recollection is that 
>> there was broad support for the idea; it's just a matter of it being 
>> in-scope so that we can figure out the syntax. Once we get that done, if we 
>> make tuples extendable we could just say (hand-wavey straw-man syntax, of 
>> course):
>> extension (Ts: _...) where Ts.count > 0, Ts.reduce(true) { $0 = 
>> Ts.Head.self == $1.self } == true {
>> subscript(_ i: Int) -> Ts.Head {...}
>> }
>> 
>> ... and just do it all through tuples. Is this a better than having a 
>> dedicated FSA type? Dunno. In large part, it depends on how difficult the 
>> various ideas will be to implement, and how useful the extra bits of 
>> functionality would be to the rest of the language. Unfortunately, the 
>> people who have those answers are busy working with the Swift 4.0 release, 
>> and likely don't have time to really weigh in on out of scope topics (which 
>> we all agree can be frustrating, but there are practical realities in life, 
>> and staying focused enough to meet deadlines is one of theirs).
>> 
>> I don’t think tuples are a suitable replacement for FSAs. A tuple should be 
>> able to be broken up and optimized by the compiler, and have no contiguity 
>> guarantees in memory.
> 
> C's static arrays are imported as tuples, which need at least some level of 
> contiguity guarantees to work. Even if tuples in general make that such a 
> guarantee, tuple-based FSAs could use the same compiler logic as imported C 
> arrays.

To be clearer, I'm not claiming that we should implement FSAs as tuples, just 
pointing out that it might be a pretty easy option if certain other proposals 
were to be accepted. IMHO, it seems premature to put a ton of time & effort 
into a FSA proposal now when there'll likely be a proposals for pretty much all 
the pieces required for the tuple-based approach as soon as these larger topics 
become in-scope. Even if we decide tuples aren't appropriate for FSAs (and 
again, I'm not arguing for or against that approach here), it seems likely to 
me that we'd want to design these features roughly together so that we can 
ensure that their syntaxes don't get in each others' ways and everything still 
feels right together for the direction Swift as a whole is going.

For example, the `ArrayStats` type in this proposal seems like it's mostly 
there as a work-around for Swift's current lack of Variadic Generics. Given 
that that's a feature we're likely to get at some point (hopefully in Swift 4.1 
or 5, but we'll have to see what's in-scope), and that we don't want to support 
superfluous bits of code hanging around the stdlib or compiler (or language 
spec, since we're talking about a bunch of new grammar rules, too), and that we 
really don't want to break source compatibility later, doesn't it make sense to 
work on Variadic Generics first and see how that informs what we want to do WRT 
FSAs?

- Dave Sweeris

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

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[David Sweeris via swift-evolution]

> On Jul 23, 2017, at 2:49 PM, David Sweeris via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
> On Jul 23, 2017, at 12:18, Taylor Swift <kelvin1...@gmail.com 
> <mailto:kelvin1...@gmail.com>> wrote:
> 
>> On Sun, Jul 23, 2017 at 2:21 PM, David Sweeris <daveswee...@mac.com 
>> <mailto:daveswee...@mac.com>> wrote:
>> 
>> On Jul 23, 2017, at 09:08, Taylor Swift <kelvin1...@gmail.com 
>> <mailto:kelvin1...@gmail.com>> wrote:
>> 
> 
>> Speaking of which, IIRC, at one point we were considering adding subscripts 
>> to tuples and using that for FSAs. I think the hangups were pretty much just 
>> that tuples can't conform to protocols and the iffy semantics of 
>> subscripting heterogeneous tuples. The former is a bit of a pain point 
>> anyway, and unless I've forgotten about some deal-breaker that was brought 
>> up in one of those threads, I think it's somewhat likely that we'll 
>> eventually do something about it. Unrelated to FSAs and subscripting tuples, 
>> we've also discussed variadic generic arguments... My recollection is that 
>> there was broad support for the idea; it's just a matter of it being 
>> in-scope so that we can figure out the syntax. Once we get that done, if we 
>> make tuples extendable we could just say (hand-wavey straw-man syntax, of 
>> course):
>> extension (Ts: _...) where Ts.count > 0, Ts.reduce(true) { $0 = 
>> Ts.Head.self == $1.self } == true {
>> subscript(_ i: Int) -> Ts.Head {...}
>> }
>> 
>> ... and just do it all through tuples. Is this a better than having a 
>> dedicated FSA type? Dunno. In large part, it depends on how difficult the 
>> various ideas will be to implement, and how useful the extra bits of 
>> functionality would be to the rest of the language. Unfortunately, the 
>> people who have those answers are busy working with the Swift 4.0 release, 
>> and likely don't have time to really weigh in on out of scope topics (which 
>> we all agree can be frustrating, but there are practical realities in life, 
>> and staying focused enough to meet deadlines is one of theirs).
>> 
>> I don’t think tuples are a suitable replacement for FSAs. A tuple should be 
>> able to be broken up and optimized by the compiler, and have no contiguity 
>> guarantees in memory.
> 
> C's static arrays are imported as tuples, which need at least some level of 
> contiguity guarantees to work. Even if tuples in general make that such a 
> guarantee, tuple-based FSAs could use the same compiler logic as imported C 
> arrays.

To be clearer, I'm not claiming that we should implement FSAs as tuples, just 
pointing out that it might be a pretty easy option if certain other proposals 
were to be accepted. IMHO, it seems premature to put a ton of time & effort 
into a FSA proposal now when there'll likely be a proposals for pretty much all 
the pieces required for the tuple-based approach as soon as these larger topics 
become in-scope. Even if we decide tuples aren't appropriate for FSAs (and 
again, I'm not arguing for or against that approach here), it seems likely to 
me that we'd want to design these features roughly together so that we can 
ensure that their syntaxes don't get in each others' ways and everything still 
feels right together for the direction Swift as a whole is going.

For example, the `ArrayStats` type in this proposal seems like it's mostly 
there as a work-around for Swift's current lack of Variadic Generics. Given 
that that's a feature we're likely to get at some point (hopefully in Swift 4.1 
or 5, but we'll have to see what's in-scope), and that we don't want to support 
superfluous bits of code hanging around the stdlib or compiler (or language 
spec, since we're talking about a bunch of new grammar rules, too), and that we 
really don't want to break source compatibility later, doesn't it make sense to 
work on Variadic Generics first and see how that informs what we want to do WRT 
FSAs?

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

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[David Sweeris via swift-evolution]

On Jul 23, 2017, at 12:18, Taylor Swift > wrote:

> On Sun, Jul 23, 2017 at 2:21 PM, David Sweeris  > wrote:
> 
> On Jul 23, 2017, at 09:08, Taylor Swift  > wrote:
> 
>> let fsa:[2 * Int] = [2 * 5, 3] // [10, 3] ???
> 
> Correct. If you wanted a multidimensional array, that'd be written "let 
> nestedFSA: [2*[5*Int]]". Or, speculating a bit, I suppose maybe "let 
> nestedFSA: [[5*Int]*2]", if we wanted there to be a column-major option. IMHO 
> all those read better than this proposal's syntax.
> 
> 
> 
> No, what I’m saying is does the phrase “[2 * 5, 3]” mean a fixed size array 
> of length two and with the elements 5 and 3, or a flexible sized array with 
> two elements 10 and 3? This is v confusing and difficult to read, especially 
> when you have actual multiplications going on such as 
> 
> let fsa:[2 * Int] = [2 * 3 * 5, 3] // [15, 3] ???

That's... huh? To me, "[2 * 3 * 5, 3]" should obviously evaluate to "[30, 3]". 
How are you getting that "[2*5*3, 3]" could be a 2-element FSA containing 15 
and 3? Are you suggesting that instead of "[value * value * value, value]", it 
could be parsed as "[modifier value * value, value]" (with `modifier` being "2 
*")? To me, that syntax would strongly suggest that the modifier only applies 
to the first element of the array, which would mean the only other option for 
parsing it would be equivalent to "[[3, 5], 3]", which is neither a match for 
fsa's type, nor a semantically valid array (the elements have to be the same 
type), nor a syntactically valid array (the nested array in the first element 
is missing its "[]").


>> Using the multiplication operator as a separator character seems like an 
>> extraordinarily bad idea.
> 
> Well, much to the dismay of my occasionally-inner Unicode fanboy, we decided 
> that we didn't want to make everyone have to figure out how to type "×" to 
> use a stdlib type (to the further dismay of my O-IUF, this is actually a 
> really good argument, especially since a likely use for FSA is in embedded or 
> systems programming, where you might need to use an editor that doesn't 
> support Unicode).
> 
> 
> The text encoding of the source code shouldn’t have any effect on the 
> compiled target? And while the ◊ or × suggestions are semi-rhetorical, given 
> a choice between difficult-to-read syntax and unicode, I’ll choose unicode 
> every time. Swift is nowhere near the first language to use unconventional 
> symbols. Inserting special characters these days is barely harder than typing 
> a capital letter. They should be used sparingly but not ruled out completely, 
> and it doesn’t seem like there are many alternatives.

I would choose the unicode route for my projects as well, but locking stdlib 
types or functionality behind unicode has been a no-go ever since Swift was 
open-sourced (and presumably before then as well, since nothing in the stdlib 
uses them). We couldn't even get the unicode operators for set notation: "∩", 
"∪", "⊂", "⊃", "⊆", "⊇", "∈", "∋", and "∖" (maybe not "∖"... it's been a 
while), accepted as alternate spellings for: "setA.intersection(setB)", 
"setA.union(setB)", etc, back in the "Set Algebra" proposal. I really doubt a 
proposal for FSAs with syntax involving unicode will be accepted. Feel free to 
try, though. Maybe there's been a change of heart since the topic last came up.

 
> I think another contender might've been "let fsa: [2 of Int]", but if you 
> want a complete list, I'll have to go back and reread the quarter-dozen or so 
> threads on FSAs that pop up whenever we lift the "out of scope" thing (but 
> before they get ruled out of scope again). Semantically speaking, "count * 
> MemoryLayout.stride" is a pretty much exactly what we're doing at the 
> storage level, so "count * Type" fits well in that regard (IMHO, anyway, 
> since we want the syntax to be concise). It also works as syntactic sugar for 
> declaring homogeneous tuples. 
> 
> If we’re actually going to try and establish a relationship between the FSA 
> asterisk and the multiplication asterisk, this is even more problematic. How 
> does the asterisk work in FSA literals, where there is no type annotation to 
> go on the right of the asterisk?

Is there a reason the existing type inference system wouldn't work?


> Also introducing contextual keywords like “of” is going to cause a huge 
> amount of problems with syntax highlighters considering how often the word 
> “of” is used as an argument label in Swift. The words “as” and “stride” 
> already make for some interesting code highlighting, “of” would take it to a 
> whole new level.

I'm not sure we should be basing decisions like this on potential bugs in the 
syntax highlighting systems of various IDEs.


> Speaking of which, IIRC, at one point we were considering adding subscripts 
> to tuples and using that for 

Re: [swift-evolution] [Pre-pitch] Conform Int (and others) to LosslessStringConvertible

[David Sweeris via swift-evolution]

> On Jul 23, 2017, at 09:15, Matheus Martins via swift-evolution 
>  wrote:
> 
> I came across what i think is an inconsistency in the standard library.
> 
> Why are some numeric types like Int not conforming to 
> LosslessStringConvertible by default while Float and Double do conform to it 
> in the standard library?
> 
> I came across this while trying to write some generic code:
> 
> func array(_ text: String) -> [T?] {
>   return text.components(separatedBy: " ").map { T($0) }
> }
> 
> It seems rather inconsistent to me that that allows me to do:
> 
> let floats: [Float] = array("1.0 2.2 3")
> 
> but i can't do:
> 
> let ints: [Int] = array("1 2 3 4 5 6")
> "type 'Int' does not conform to protocol 'LosslessStringConvertible'"
> 
> To further my point, Int is used as the sole example in the 
> LosslessStringConvertible docs: 
> http://swiftdoc.org/v3.0/protocol/LosslessStringConvertible/
> Yet it does not actually conform to it.
> 
> This seems way too basic for me to feel comfortable pitching it here, but i 
> searched and couldn't find any discussion on this on any mailing list or 
> website.

Sounds like it's a bug to me, either in the docs or stdlib, depending on the 
intended behavior. Although I doubt they would've used Int in the docs if they 
weren't intending Int to conform to it.

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

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[David Sweeris via swift-evolution]

> On Jul 23, 2017, at 09:08, Taylor Swift  wrote:
> 
> let fsa:[2 * Int] = [2 * 5, 3] // [10, 3] ???

Correct. If you wanted a multidimensional array, that'd be written "let 
nestedFSA: [2*[5*Int]]". Or, speculating a bit, I suppose maybe "let nestedFSA: 
[[5*Int]*2]", if we wanted there to be a column-major option. IMHO all those 
read better than this proposal's syntax.



> Using the multiplication operator as a separator character seems like an 
> extraordinarily bad idea.

Well, much to the dismay of my occasionally-inner Unicode fanboy, we decided 
that we didn't want to make everyone have to figure out how to type "×" to use 
a stdlib type (to the further dismay of my O-IUF, this is actually a really 
good argument, especially since a likely use for FSA is in embedded or systems 
programming, where you might need to use an editor that doesn't support 
Unicode).

I think another contender might've been "let fsa: [2 of Int]", but if you want 
a complete list, I'll have to go back and reread the quarter-dozen or so 
threads on FSAs that pop up whenever we lift the "out of scope" thing (but 
before they get ruled out of scope again). Semantically speaking, "count * 
MemoryLayout.stride" is a pretty much exactly what we're doing at the 
storage level, so "count * Type" fits well in that regard (IMHO, anyway, since 
we want the syntax to be concise). It also works as syntactic sugar for 
declaring homogeneous tuples.

Speaking of which, IIRC, at one point we were considering adding subscripts to 
tuples and using that for FSAs. I think the hangups were pretty much just that 
tuples can't conform to protocols and the iffy semantics of subscripting 
heterogeneous tuples. The former is a bit of a pain point anyway, and unless 
I've forgotten about some deal-breaker that was brought up in one of those 
threads, I think it's somewhat likely that we'll eventually do something about 
it. Unrelated to FSAs and subscripting tuples, we've also discussed variadic 
generic arguments... My recollection is that there was broad support for the 
idea; it's just a matter of it being in-scope so that we can figure out the 
syntax. Once we get that done, if we make tuples extendable we could just say 
(hand-wavey straw-man syntax, of course):
extension (Ts: _...) where Ts.count > 0, Ts.reduce(true) { $0 = 
Ts.Head.self == $1.self } == true {
subscript(_ i: Int) -> Ts.Head {...}
}

... and just do it all through tuples. Is this a better than having a dedicated 
FSA type? Dunno. In large part, it depends on how difficult the various ideas 
will be to implement, and how useful the extra bits of functionality would be 
to the rest of the language. Unfortunately, the people who have those answers 
are busy working with the Swift 4.0 release, and likely don't have time to 
really weigh in on out of scope topics (which we all agree can be frustrating, 
but there are practical realities in life, and staying focused enough to meet 
deadlines is one of theirs).

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

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[David Sweeris via swift-evolution]

Sent from my iPhone

> On Jul 23, 2017, at 08:45, Taylor Swift via swift-evolution 
>  wrote:
> 
> 
> 
>> On Sun, Jul 23, 2017 at 5:29 AM, Adrian Zubarev via swift-evolution 
>>  wrote:
>> I wanted to read the proposal, but skipped it as soon as I’ve seen the 
>> syntax. From the esthetic point of you the proposed syntax is really ugly. 
>> Again I’m not speaking against the feature in general, nor against any of 
>> the technical benefits fixed-size array will provide to us. I simply dislike 
>> the syntax, which in my opinion does not fit to Swift.
>> 
> 
> What about a double colon?
> 
> let fsa:[5, 2::Int] = [5, 2::[::0, 0]: 5, [::5, 1]: 6, default: -1]

I thought we'd mostly settled on "let fsa: [count * Type]" last time this came 
up.

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

Re: [swift-evolution] [Proposal] Associated Type and Generic One-to-One Mapping

[David Sweeris via swift-evolution]

Would that even compile? I thought I'd remembered getting an "illegal 
redefinition of T" or some such error, but maybe I'm misremembering (plus, I 
haven't tried in a really long time).

- Dave Sweeris 

> On Jun 24, 2017, at 08:48, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> For every Bar.T that is currently distinct from Foo.T, this would be 
> source-breaking.
>> On Sat, Jun 24, 2017 at 01:51 David Sweeris via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> > On Jun 23, 2017, at 5:28 PM, David Moore via swift-evolution 
>> > <swift-evolution@swift.org> wrote:
>> >
>> > I do indeed have quite a few real examples of this, such prompted me to 
>> > bring this up. I think this could be done without any impact to existing 
>> > code, but it would require some type of keyword. Take the following as a 
>> > possible prototype.
>> >
>> > protocol Foo {
>> > associatedtype T
>> > }
>> >
>> > struct Bar : Foo {
>> > keyword typealias T // Or really any other syntactical implementation.
>> > }
>> >
>> > With an opt-in method we could implement this without affecting existing 
>> > code, thereby making this more viable. I will send some examples later.
>> 
>> At one point there was talk of just having generic parameters automatically 
>> becoming typealiases:
>> struct Bar : Foo {
>> // `T` is automatically an implicit typealias for, well, `T`
>> }
>> 
>> Dunno if that’s still the plan (or to what degree it ever was), but it’d 
>> work for me. I don’t even think it’d break source compatibility (though it 
>> may make a lot of typealiases unneeded.
>> 
>> - Dave Sweeris
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Associated Type and Generic One-to-One Mapping

[David Sweeris via swift-evolution]

> On Jun 23, 2017, at 5:28 PM, David Moore via swift-evolution 
>  wrote:
> 
> I do indeed have quite a few real examples of this, such prompted me to bring 
> this up. I think this could be done without any impact to existing code, but 
> it would require some type of keyword. Take the following as a possible 
> prototype.
> 
> protocol Foo { 
> associatedtype T
> }
> 
> struct Bar : Foo {
> keyword typealias T // Or really any other syntactical implementation.
> }
> 
> With an opt-in method we could implement this without affecting existing 
> code, thereby making this more viable. I will send some examples later.

At one point there was talk of just having generic parameters automatically 
becoming typealiases:
struct Bar : Foo {
// `T` is automatically an implicit typealias for, well, `T`
}

Dunno if that’s still the plan (or to what degree it ever was), but it’d work 
for me. I don’t even think it’d break source compatibility (though it may make 
a lot of typealiases unneeded.

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

Re: [swift-evolution] floating point numbers implicit conversion

[David Sweeris via swift-evolution]

Sent from my iPhone
> On Jun 19, 2017, at 13:44, John McCall via swift-evolution 
>  wrote:
> 
>>> On Jun 19, 2017, at 1:58 PM, Stephen Canon via swift-evolution 
>>>  wrote:
>>> On Jun 19, 2017, at 11:46 AM, Ted F.A. van Gaalen via swift-evolution 
>>>  wrote:
>>> 
>>> var result: Float = 0.0
>>> result = float * integer * uint8 +  double   
>>> // here, all operands should be implicitly promoted to Double before the 
>>> complete expression evaluation.
>> 
>> You would have this produce different results than:
>> 
>>  let temp = float * integer * uint8
>>  result = temp + double
>> 
>> That would be extremely surprising to many unsuspecting users.
>> 
>> Don’t get me wrong; I *really want* implicit promotions (I proposed one 
>> scheme for them  way back when Swift was first unveiled publicly).
> 
> I don't!  At least not for floating point.  It is important for both reliable 
> behavior and performance that programmers understand and minimize the 
> conversions they do between different floating-point types.

How expensive is it?

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

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

[David Sweeris via swift-evolution]

> On Jun 19, 2017, at 11:45, Robert Bennett via swift-evolution 
>  wrote:
> 
> +1 for member variables, -1 for member functions. Functions take up too much 
> vertical space to make this convenient; 

Yeah, I think that really only made sense in the world of header files, where 
function declarations were only one line each.

Off the top of my head, I wouldn't oppose it for non-computed properties, 
though.

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

Re: [swift-evolution] floating point numbers implicit conversion

[David Sweeris via swift-evolution]

Off the top of my head? As the language stands now, maybe a ton of extensions 
so that it never actually hits the fully generic version?

extension Addable where Self == Int8 {...}
extension Addable where Self == Int16 {...}
extension Addable where Self == Int32 {
  static func +  (lhs: Self, rhs: Int8) -> Self {...}
  static func +  (lhs: Self, rhs: Int16) -> Self {...}
  static func +  (lhs: Self, rhs: Int32) -> Self {...}
  static func +  (lhs: Self, rhs: Int64) -> Int64 {...}
}
extension Addable where Self == Int64 {...}

Dunno if that'll compile... it might need an `_IntNNType` protocol for each 
integer type so that the where clause could be "where Self: _Int32Type" instead 
of "where Self == Int32" (of course, if such a thing were actually done, the 
obvious next step would be to make `UInt64` conform to `_Int8Type`, and see 
just how close you can get to wat https://www.destroyallsoftware.com/talks/wat).

Even if that works, though, it'll all come crashing down as soon as someone 
makes an `Int128`... oh, nuts! I forgot about `DoubleWidth`!

Yeah, I don't think I can just pull that particular implementation out of the 
air.

- Dave Sweeris

> On Jun 17, 2017, at 21:18, Xiaodi Wu  wrote:
> 
> And, without integer literals as generic parameters, how would you express 
> this operation?
> 
> 
>> On Sat, Jun 17, 2017 at 23:01 David Sweeris  wrote:
>> 
>>> On Jun 17, 2017, at 20:43, Xiaodi Wu  wrote:
>>> 
>>> In Swift, all types and all operators are implemented in the standard 
>>> library. How do you express the idea that, when you add values of disparate 
>>> types T and U, the result should be of the type with greater precision? You 
>>> need to be able to spell this somehow.
>> 
>> Oh, ok... I thought you meant "conditional conformance" or something 
>> concrete :-D
>> 
>> Off the top of my head, with "literals as generic parameters",
>> protocol Addable {
>>   associatedtype BitsOfPrecision: IntegerLiteral
>>   static func +  (_: Self, _: T) -> T where T.BitsOfPrecision >
>> BitsOfPrecision
>>   static func +  (_: Self, _: T) -> Self where T.BitsOfPrecision 
>> <= BitsOfPrecision
>> }
>> 
>> Although, come to think of it, I suppose that's a bit more than simply using 
>> literals as types. Still, it's all information that's available at compile 
>> time, though.
>> 
>> - Dave Sweeris 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] floating point numbers implicit conversion

[David Sweeris via swift-evolution]

> On Jun 17, 2017, at 20:43, Xiaodi Wu  wrote:
> 
> In Swift, all types and all operators are implemented in the standard 
> library. How do you express the idea that, when you add values of disparate 
> types T and U, the result should be of the type with greater precision? You 
> need to be able to spell this somehow.

Oh, ok... I thought you meant "conditional conformance" or something concrete 
:-D

Off the top of my head, with "literals as generic parameters",
protocol Addable {
  associatedtype BitsOfPrecision: IntegerLiteral
  static func +  (_: Self, _: T) -> T where T.BitsOfPrecision >
BitsOfPrecision
  static func +  (_: Self, _: T) -> Self where T.BitsOfPrecision <= 
BitsOfPrecision
}

Although, come to think of it, I suppose that's a bit more than simply using 
literals as types. Still, it's all information that's available at compile 
time, though.

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

Re: [swift-evolution] floating point numbers implicit conversion

[David Sweeris via swift-evolution]

> On Jun 17, 2017, at 16:16, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Sat, Jun 17, 2017 at 3:21 PM, Ted F.A. van Gaalen  
>> wrote:
>> 
>> As you know, Swift currently does not facilitate implicit conversion 
>> (coercion),
>> which implies that current code (which of course does not contain implicit 
>> conversions) 
>> will function exactly as it does now,
> 
> That is not implied. Swift has type inference, which means that, with the 
> implementation of implicit promotion, the inferred type of certain 
> expressions that are legal today will change. For instance, integer literals 
> have no type of their own and are inferred to be of some type or another 
> based on context. When combined with bitwise operators, the presence or 
> absence of overloads that allow heterogeneous operations can change the 
> result of code that compiles both before and after the implementation of the 
> feature. This is just one example of why implicit integer promotion in a 
> strictly typed language with type inference and without certain generics 
> features is very hard.

I'm not sure which generic features you're referring to. Would you (or anyone 
else who knows) mind elaborating?

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

Re: [swift-evolution] Swift phases and mis-timed proposals

[David Sweeris via swift-evolution]

> On Jun 12, 2017, at 7:16 PM, Jonathan Hull via swift-evolution 
>  wrote:
> 
>> On Jun 12, 2017, at 5:12 PM, Ted Kremenek via swift-evolution 
>> > wrote:
>> 
>>> On Jun 12, 2017, at 12:47 PM, Paul Cantrell  wrote:
>>> 
>>> Concern #2 is that it’s hard to know what to do with a proposal when the 
>>> ideal answer is “we need to see how it plays out in practice and then 
>>> decide whether to accept it.” Theoretical discussion untempered by 
>>> practical prototyping is a great way for a group to talk itself into a bad 
>>> idea. (This will especially be a problem with future work to build out 
>>> generics & existentials.)
>> 
>> I agree.  Do you have specific thoughts here on what could be done 
>> differently?
> 
> I think we can partially solve this by having an extra stage of “stability” 
> in our documentation.  Right now, things are either officially part of the 
> language or they aren’t (with a very short beta period between WWDC and the 
> Fall).  What I would like to see in the documentation is a notion of how sure 
> we are of a particular piece of API or syntax.
> 
> Unstable - This is actively under development/design and should be expected 
> to change. It is not safe to build frameworks on top of this.
> 
> Pre-Stable - We think we have a design which works, but we need to see how it 
> works in the larger ecosystem before guaranteeing stability.  Anything built 
> on this should be prepared for potentially large changes in the future, and 
> be marked “Pre-Stable” themselves.
> 
> Stable - This has been extensively tested in the actual swift ecosystem and 
> proven itself a useful addition.  Any changes to this in the future are 
> guaranteed to either be source-compatible or have a full depreciation cycle. 
> It is completely safe to build on.
> 
> I think being explicit about what we expect to change in the future, and 
> having a notion of “stable” that is truly stable will give us a lot more 
> freedom to experiment as well as room to fix our mistakes.

I’m not sure documentation is sufficient… If I only wanted to use the “stable” 
features, would I have to read the docs on every standard library type I use? 
And what about unstable or pre-stable compiler features? It’s not like I can 
right-click on a var and get the type inference rules, for example.

Now, I wouldn’t mind the ability to vote (or at the core team’s discretion) 
that we accept a proposal into a separate “pre-stable” or “staging” toolchain, 
with the understanding that if it doesn’t cause any major issues it’ll 
automatically be accepted for the next major release. If issues are found, then 
we’d have a chance to re-review & refine the proposal before committing it to 
the main toolchain and its source-compatibility requirements. If, upon 
re-review, the proposal is rejected, it would be deprecated in the next major 
release’s staging toolchain and removed in the major release after that.

To clarify, the timeline would be something like:

Prior to Swift N: We accept SE- for Swift N, as well as SE- and SE- 
for Swift N Staging.
Release Swift N:
- Standard: implements SE-
- Staging: implements SE- and SE-
Prior to Swift N+1: We accept a proposal to revert SE- because it turns out 
to be a horrible idea
Release Swift N+1:
- Standard: implements SE-, SE-
- Staging: deprecates SE-
Release Swift N+2:
- Standard: implements SE-, SE-
- Staging: reverts SE-

This would give the people whose code relies on SE- probably between 1-2 
years to find a work-around, given the current pace of major releases, and 
depending on exactly where in the timeline the problems get discovered. (As a 
last resort, you could leave the Swift N or N+1 staging toolchains installed, 
refactor any features relying on SE- into their own module, and move the 
rest of your app’s code on to Swift N+2. Certainly not ideal, but AFAIK, it's 
an option.) And if you’re worried about it, just use the stable toolchain.

I do have some concerns, though… My understanding is that Rust does something 
similar and has an “experimental” compiler release… Apparently, all the “cool” 
stuff is done there, which makes it the “standard" compiler, and relegates the 
actually-stable compiler to “old version” status. Or so I hear, anyway. I 
haven’t really used it much. Anyway, I wouldn’t want us to get in a position 
where everyone’s using some feature of the staging toolchain, but we can’t 
merge it into the stable toolchain because maybe it breaks some niche use-case 
that we need to support or something. We do have one thing going for us, 
though, that Rust doesn’t… a large portion of Swift’s user base needs to ship 
to Apple's App stores, and Apple controls what toolchains you’re allowed to use 
for that. OTOH, if we say "no staging toolchain for the app 

Re: [swift-evolution] Swift phases and mis-timed proposals

[David Sweeris via swift-evolution]

> On Jun 13, 2017, at 11:46 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> I imagine that recent discussions like mapped keypaths, ordered sets, 
> `count(where:)`, etc. could have a home for discussion and exploration 
> without getting blocked by "out of scope" if there were a separate 
> "Substandard Library" repository, mailing list, and process (potentially 
> staffed in part or full by non-Apple personnel) that did not rely on internal 
> Apple timelines and delivery benchmarks. Think "farm league for SE" 
> (https://en.wikipedia.org/wiki/Farm_team 
> ). It would lower the burden on SE 
> but provide a way forward to discuss and develop ideas within the framework 
> of coherent language design.

+1

Not even just for development… a standard repository for “substandard” 
library(s) would be a great for commonly used types that aren’t quite commonly 
used enough to include in stdlib, and IMHO, could really help Swift’s ecosystem 
(I’m not claiming that it’s poor now or anything, but there’s nothing wrong 
with making it the best we can).

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

Re: [swift-evolution] Swift phases and mis-timed proposals

[David Sweeris via swift-evolution]

> On Jun 13, 2017, at 12:34 AM, John McCall  wrote:
> 
>> On Jun 13, 2017, at 3:22 AM, David Sweeris > > wrote:
>>> On Jun 13, 2017, at 12:18 AM, John McCall via swift-evolution 
>>> > wrote:
>>> 
 On Jun 13, 2017, at 1:08 AM, Jacob Bandes-Storch via swift-evolution 
 > wrote:
 On Mon, Jun 12, 2017 at 9:31 PM, Paul Cantrell via swift-evolution 
 > wrote:
 I support everything Jon wrote.
 
 +1 Free-for-all brainstorming venue separate from focused proposal 
 discussion.
 
 +1, particularly for this being a section in Discourse ;-)
>>> 
>>> You posted this with a wink, but I think it's actually quite important.  I 
>>> see some value in having a "sounding board" area where people can talk 
>>> through ideas that maybe aren't anywhere close to proposal yet
>> 
>> FWIW, I’ve had a few off-list discussions of that nature and found them to 
>> be incredibly valuable.
> 
> I'm certainly not trying to discourage anyone from having off-list 
> discussions.  Have a conversation whenever and wherever it strikes you.  But 
> I do think it would be really unfortunate to try to set somewhere else up as 
> a permanent alternative venue.

Oh! I was unclear… The discussions themselves were what’s valuable. The only 
reason they were off-list was to avoid spamming the list with premature ideas. 
Given the choice, I’d prefer to have them in an official “off-topic”/“sounding 
board”/whatever area.

- Dave Sweeris


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

Re: [swift-evolution] Swift phases and mis-timed proposals

[David Sweeris via swift-evolution]

> On Jun 13, 2017, at 12:18 AM, John McCall via swift-evolution 
>  wrote:
> 
>> On Jun 13, 2017, at 1:08 AM, Jacob Bandes-Storch via swift-evolution 
>> > wrote:
>> On Mon, Jun 12, 2017 at 9:31 PM, Paul Cantrell via swift-evolution 
>> > wrote:
>> I support everything Jon wrote.
>> 
>> +1 Free-for-all brainstorming venue separate from focused proposal 
>> discussion.
>> 
>> +1, particularly for this being a section in Discourse ;-)
> 
> You posted this with a wink, but I think it's actually quite important.  I 
> see some value in having a "sounding board" area where people can talk 
> through ideas that maybe aren't anywhere close to proposal yet

FWIW, I’ve had a few off-list discussions of that nature and found them to be 
incredibly valuable.

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

Re: [swift-evolution] [Proposal] Change Void meaning

[David Sweeris via swift-evolution]

> On Jun 12, 2017, at 10:45 PM, Gwendal Roué via swift-evolution 
>  wrote:
> 
> "Discussing" with Xiaodi is a special experience, isn't it?
> 
> He will bite and misrepresent you and your ideas until you get tired and your 
> idea has been exhausted to death and diluted in dozens of useless messages. 
> Don't feed him.

That’s pretty much the exact opposite of my experiences talking to him. He’s a 
great guy.

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

Re: [swift-evolution] Rekindling: "Extending declaration scope to condition for `repeat { } while ()"

[David Sweeris via swift-evolution]

> On Jun 12, 2017, at 5:13 PM, Pavol Vaskovic via swift-evolution 
>  wrote:
> 
> On Sun, Jun 11, 2017 at 1:52 AM, Haravikk via swift-evolution 
> > wrote:
> 
> With the ability to specify throwaway variables more easily, I'm sticking 
> with my using syntax here:
> 
> var theNames:[String] = []
> while let eachItem = theIterator.next() using (var theTotal = 0) where 
> (theTotal < 100) {
>   theNames.append(eachItem.name)
>   theTotal += eachItem.value
> }
> 
> Depending upon your preference on how to structure the using and where parts 
> this is shorter and easier.
> 
> I think you just reinvented the C-style for loop, that was removed in SE-0007 
> .
Eh, as long as a feature wasn’t removed for security or correctness reasons 
(which isn’t the case with SE-0007), I don’t see a problem with one proposal 
enabling functionality that was removed by another. It’s not like we said 
C-style for loops are evil or anything, just that they weren’t right for Swift. 
If it turns out that something which otherwise is right for Swift can be 
“abused” to get C-style for loop semantics, then those who voted against 
SE-0007 are free to try out this new syntax and see if that helps them. IMHO, 
anyway.

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

Re: [swift-evolution] [Proposal] Change Void meaning

[David Sweeris via swift-evolution]

> On Jun 12, 2017, at 10:44, Jérémie Girault via swift-evolution 
>  wrote:
> 
> Void was the empty tuple because arguments were tuples. So no arguments meant 
> empty tuple.
> 
> If we consider the empty tuple to be an argument, then the type for the type 
> of empty tuple should be `Unit`
> 
> Void, however, seem naturally fitted for the absence of argument.
> 
> Should `func foo(Void)` be different from `func foo()`? I don’t think so. But 
> different from `func foo(Unit)` ? Yes !
> 
To me, "Unit" is used like "a unit of length", "a unit of time", etc. I've not 
come across it being used as analog for something like the empty tuple.

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

Re: [swift-evolution] Swift phases and mis-timed proposals

[David Sweeris via swift-evolution]

> On Jun 11, 2017, at 14:41, Haravikk via swift-evolution 
>  wrote:
> 
> Thing is; people are going to have ideas when they have them, and want to 
> discuss them right away. I've been caught out numerous times with proposals 
> that are almost immediately rejected as out of scope, and still have no idea 
> when I'm supposed to resubmit them.
> 
> To be honest it's demoralising, as I find myself apathetic towards my own 
> ideas as I have no idea when to revisit them, and by the time I do I've 
> largely lost interest and moved on to other things.

Yeah, I hope we'll get an "out of scope" section when we move to discourse... 
That way the core team and others who are busy can focus on what's practical 
for the next release, and those of us who have ideas that are a bit premature 
will have a place to discuss and refine them (and one where we don't have to 
spend an hour or so combing through our social media history just to find it).

Either way, though, I think restricting ourselves to a set of "in-scope" topics 
is likely about the only way we'll be able to collectively stay focused enough 
to get anything done.

- Dave Sweeris 

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

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

[David Sweeris via swift-evolution]

> On Jun 9, 2017, at 16:38, Daryle Walker via swift-evolution 
>  wrote:
> 
> 
>> On Jun 9, 2017, at 12:14 AM, Yvo van Beek via swift-evolution 
>>  wrote:
>> 
>> Typealiases can greatly reduce the complexity of code. But I think one 
>> change in how the compiler handles them could make them even more powerful.
> [SNIP]
>> Perhaps it would be better if the extension would only apply to the parts of 
>> my code where I use the HeaderKey typealias and not to all Strings. This 
>> could be a great tool to specialize classes by creating a typealias and 
>> adding functionality to it. Another example I can think of is typealiases 
>> for dictionaries or arrays with added business logic through extensions 
>> (especially since you can't inherit from structs).
>> 
>> If you want to create an extension that adds functionality to all Strings 
>> you could have created an extension for String instead of HeaderKey.
>> 
>> Please let me know what you think. I'm not sure how complex this change 
>> would be.
>> I could write a proposal if you're interested.
> 
> Isn’t the point of “typealias" is that it does NOT have any change in 
> semantics? The compiler doesn’t even have to acknowledge aliases in any 
> run-time type tables, it just references the existing row of what the alias 
> points to (based on a compile-time type table).
> 
> As others suggested, this new semantic could be moved to a new type concept 
> (with a new keyword).

Agreed... +1 for something like "newtype", -1 for hoisting that functionality 
onto "typealias".

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

Re: [swift-evolution] History and future of Swift's parentheses

[David Sweeris via swift-evolution]

> On Jun 9, 2017, at 8:12 AM, Gor Gyolchanyan via swift-evolution 
>  wrote:
> 
>> 
>> So I wonder if any of you have had any thoughts about what Swift's 
>> parentheses-related future (or evolutionary baggage) will be?
>> 
> 
> I really wish swift used the concept of tuples **exclusively** for all 
> purposes that involve parentheses, as well as dividing tuples into two 
> categories:
> - Bare tuples, which do not have labels.
> - Rich tuples, which do.
> As a consequence, here's a list of statements that would become true:
> - All functions take exactly one parameter, which is a tuple.

That’s what we used to do. It caused problems with other language features 
(“inout" and “variadic" parameters were the two big ones, IIRC).

- Dave Sweeris

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

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

[David Sweeris via swift-evolution]

> On Jun 8, 2017, at 05:09, Gor Gyolchanyan via swift-evolution 
>  wrote:
> 
> Disclaimer: I do realize that any of the following ideas may have been 
> discussed before and/or there might be a good reason for their lack of 
> implementation, so please go easy in me. 
> 
> 1. Arbitrary `self` Assignments In Intializers
> 
> The first ideas is to allow `self = nil` inside failable initializers 
> (essentially making `self` look like `inout Self?` instead of `inout Self` 
> with magical `return nil`), so that all initializers uniformly can be written 
> in `self = ...` form for clarity and convenience purposes. This should, 
> theoretically, be nothing but a `defer { return nil }` type of rewrite, so I 
> don't see any major difficulties implementing this. This is especially useful 
> for failable-initializing enums where the main switch simply assigns to self 
> in all cases and the rest of the initializer does some post-processing.
> 
> 2. Arbitrary `return` Statements In Intializers
> 
> The second idea is to allow `return ...` inside all initializers, which 
> should also, theoretically, be a simple rewrite to `self = ...; return`. This 
> one is to complement the existing `return nil` and allow some super-short 
> initializers with a switch that returns in all cases or a more complex 
> initializer that has a lot of guard statements.
> 
> 2.1. Future Factory Initializers
> 
> In addition, the `return ...` syntax has the benefit for potential factory 
> initializers. So far, the proposals for factory initializers involved a 
> keyword attached to the initializer, which just complicates the lexical 
> structure of the language and adds unnecessary complication to the interface 
> of types. Currently, factory initializers imported from Objective-C or from C 
> using the `__attribute__((swift_name("MyType.init(self:...)")))` look like 
> normal initializers (an in case of C, the return value doesn't even have to 
> be related to the enclosing type in any way), but behave as you'd expect: you 
> call the initializer and the result is a value that *should* be a subtype of 
> the type you've called the initializer for. So, if in the future Swift gets 
> native factory initializers (including, most importantly, in protocols), it 
> won't require special syntax, because simply returning an instance of a 
> subtype (with a compile-time check, of course) would look and behave very 
> intuitively. This would also be very useful for singletons, which would use a 
> private initializer for creating the instance and a public factory 
> initializer for returning it.
> 
> 3. Failable Member Initialization
> 
> The third idea is to allow writing `self.member = MemberType?(...)` or 
> `self.member = .init?(...)` (the exact syntax is up to debate) inside 
> failable initializers, which would be simply rewritten as:
> 
> guard let _self_member = MemberType(...)  else {
>return nil
> }
> self.member = _self_member
> 
> This will dramatically reduce the boilerplate and visual clutter form complex 
> failable initializers that call other failable initializers. A good use case 
> would be complex `LosslessStringConvertible` types with many 
> `LosslessStringConvertible` members.
> 
> So, what do you guys think?

#1 & #3 would violate Swift's rule about having to fully initialize all 
properties in inits.

My initial reaction is to like #2, though, assuming I understand it correctly.

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

Re: [swift-evolution] [Meta] WWDC week

[David Sweeris via swift-evolution]

+1, feels like it matches swift's direction

Sent from my iPhone

On Jun 5, 2017, at 20:53, Brent Royal-Gordon  wrote:

>> On May 30, 2017, at 10:26 PM, Brent Royal-Gordon  
>> wrote:
>> 
>> I'm going to be in San Jose during WWDC next week, and I'm assuming I won't 
>> be the only one. Are there any swift-evolution meetings or events planned? 
>> Personally, I'd love to put some faces to names (not that I'm very good with 
>> faces, or names for that matter).
> 
> 
> How does Friday sound to people? Based on a couple of Twitter responses, it 
> seems to be pretty open, and it has the advantage that nobody's gonna have a 
> talk or event the next day that they need to prepare for.
> 
> (Actually, technically *I* might have a talk back home the next day. But 
> that's a different story!)
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Can functions/methods be overloaded on mutability of parameters?

[David Sweeris via swift-evolution]

> On Jun 2, 2017, at 22:29, Daryle Walker via swift-evolution 
>  wrote:
> 
> Can I make two overloads such that one can take an argument from a “let”-mode 
> object or a regular function parameter and return an UnsafePointer and then 
> have the other take a “var”-mode object or inout function parameter and 
> return an UnsafeMutablePointer? I think this can be done in C++.

Yeah, I think. Make the "var mode" version take an inout argument. You'll still 
be able to call the "let mode" version with a var, but you can't pass lets as 
an inout parameter.

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

Re: [swift-evolution] Yet another fixed-size array spitball session

[David Sweeris via swift-evolution]

> On May 31, 2017, at 10:38 AM, Tino Heth via swift-evolution 
>  wrote:
> 
> I don't want to write things like "Vector3D" and "Vector4D" to wrap a static 
> array just to ensure that it has the right size, and I don't want to have 
> runtime-checks which would decrease the performance-benefit.

+1

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

Re: [swift-evolution] Yet another fixed-size array spitball session

[David Sweeris via swift-evolution]

> On May 30, 2017, at 03:25, Pavol Vaskovic  wrote:
> 
>> On Tue, May 30, 2017 at 7:51 AM, David Sweeris  wrote:
>> 
>> `(Int, Int, Int, Int)` isn't *that* horrible compared to "[Int x 4]", but 
>> would you want to replace "[Int8 x 1]" with the multipage-long tuple 
>> equivalent?
> 
> 
> It would be really helpful to my understanding, if you spoke about a 
> practical use case. This reads as a contrived counterexample to me…
> 
> If your type really has 10 000 values in it, why does it have to be static, 
> why doesn't normal Array fit the bill?

Sure, I meant it as an example of how unwieldy large tuples can be. Even medium 
ones, really. Tuples are great for bundling a few values, but much more than 
that any they become annoying to work with because there's no easy way to 
iterate through them. As a more realistic example, what if you want a 
stack-allocated 256-element buffer (which is a real possibility since 
statically-allocated C arrays are imported as tuples)? You have to manually 
keep track of i, because you have to hard-code which element you're addressing 
("buf.0", "buf.1", etc), rather than being able to look it up directly from an 
index variable like, well, an array ("buf[i]").

Plus the fact that they can't conform to protocols really limits their 
usefulness in filling the role of a "normal" type. For instance, even though 
you could easily create the normal, 64-bit hash value from an instance of a 
`(Int32, Int32)` simply by concatenating the two elements' bits, you can't 
create a `Dictionary<(Int32, Int32), SomeType>` because there's no mechanism to 
get `(Int, Int)` to conform to Dictionary's `Hashable` requirement.

Could both of these features get added to Tuples? From a technically PoV, sure, 
and it's been discussed in previous threads. IMHO we'd get more benefit out of 
adding support for variadic generic parameters and using literal values as 
generic parameters (both of which have also been previously discussed).

But it's all out of scope until after Swift 4 comes out, because none of this 
affects ABI or source-code compatibility.

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

Re: [swift-evolution] Yet another fixed-size array spitball session

[David Sweeris via swift-evolution]

> On May 29, 2017, at 22:03, Pavol Vaskovic via swift-evolution 
>  wrote:
> 
> I'm sorry if I'm misunderstanding your proposal, but I think Swift already 
> has "array types whose size is fixed at compile time" called Tuple.

Tuples don't support subscripting or protocol conformance. Or an easy syntax to 
declare/initialize them... `(Int, Int, Int, Int)` isn't *that* horrible 
compared to "[Int x 4]", but would you want to replace "[Int8 x 1]" with 
the multipage-long tuple equivalent?

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

Re: [swift-evolution] Yet another fixed-size array spitball session

[David Sweeris via swift-evolution]

> On May 29, 2017, at 2:39 PM, Nicolas Fezans  wrote:
> 
> There are many aspects in the initial proposal that certainly need a more 
> expert eye than mine. I have one question though. It seems to me that the 
> constant expressions as known as constexpr in C++11 would be allowed as well. 
> Is that right? If yes, are there any differences in the proposal to what is 
> allowed in C++11? 

There’s enough interest in a “constexpr” feature that I suspect it (or 
something like it) will eventually get added, but as far as I know it’s not on 
any official todo list or roadmap or anything.

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

Re: [swift-evolution] Yet another fixed-size array spitball session

[David Sweeris via swift-evolution]

> On May 29, 2017, at 01:12, Tino Heth via swift-evolution 
>  wrote:
> 
> I agree strongly that the syntax looks awkward — imho
> var v: Vector
> would be a much better fit than
> var v array 3 of Int
> 
> As much as I want to have "real" arrays, I don't think we should add new 
> keywords for them.

Yeah, a "fixed-size array" is probably the most obvious use-case for allowing 
literal values to be generic parameters. In fact, at that point, they'd just be 
another type... no special support needed, other than validating the count when 
assigning array literals to them.

The syntax that gained some traction last time they were seriously discussed 
would also be better, IMHO:
let x: [Int x 4]
or maybe it was this?
let x: [Int * 4]
Either way, it's more concise, far easier to read (IMHO), and doesn't need new 
keyword(s).

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

Re: [swift-evolution] Revisiting SE-0110

[David Sweeris via swift-evolution]

> On May 26, 2017, at 08:14, Robert Bennett via swift-evolution 
>  wrote:
> 
> Alternatively, for maximum consistency we could make "{ arg in ..." illegal 
> as well, requiring parentheses around "arg". This would mirror the 
> parentheses necessary in e.g., "let f: (Int) -> Int", and there would be no 
> confusion as to why " { arg in ..." is legal but not "{ (key, value) in ...".

I think I would support that. Until quite recently, I was under the impression 
that closures' "inner signatures" were part of that proposal, anyway.

(Come to think of it... were they? I suppose it could be a bug that the "old" 
syntax is still accepted here.)

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

Re: [swift-evolution] Pitch: Allow generic functions to fulfill non-generic protocol requirements

[David Sweeris via swift-evolution]

> On May 24, 2017, at 5:52 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> On Wed, May 24, 2017 at 7:21 PM, David Sweeris <daveswee...@mac.com 
> <mailto:daveswee...@mac.com>> wrote:
> 
>> On May 24, 2017, at 5:11 PM, Xiaodi Wu <xiaodi...@gmail.com 
>> <mailto:xiaodi...@gmail.com>> wrote:
>> 
>> On Wed, May 24, 2017 at 3:32 PM, David Sweeris via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> So, I’m working on a type, and would like to make it conform to 
>> `ExpressibleByArrayLiteral`. The thing is, I don’t actually care what type 
>> `Element` is as long as it conforms to `FixedWidthInteger` and 
>> `UnsignedInteger`. I tried writing this:
>>   public init  (arrayLiteral 
>> elements: U...) { … }
>> But Xcode says my type doesn’t conform to `ExpressibleByArrayLiteral` unless 
>> I add an init that takes a concrete type:
>>   public init(arrayLiteral elements: UInt...) { … }
>> 
>> Does anyone else think the generic init should to be able to satisfy 
>> `ExpressibleByArrayLiteral` (especially since `UInt` meets the conformance 
>> requirements)?
>> 
>> Your type needs to be generic.
> 
> It already is… I just don’t want to restrict it to being initialized from 
> array literals containing that same generic type.
> 
> Not sure of your particular use case, but it sounds like you'd want to write 
> a type-erased AnyFixedWidthUnsignedInteger wrapper.


It’s just a arbitrary-width integer type. It's generic over a “chunk” type: 
UIntArb, UIntArb, etc. I was just wanting to be able initialize 
the chunk array using an array literal containing any FixedWidthInteger & 
UnsignedInteger type is all. I’ll look into the type-erased wrapper thing, but 
I doubt it’ll be worth the effort since it was just a minor convenience issue 
for me in the first place.

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

Re: [swift-evolution] Pitch: Allow generic functions to fulfill non-generic protocol requirements

[David Sweeris via swift-evolution]

> On May 24, 2017, at 5:11 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> On Wed, May 24, 2017 at 3:32 PM, David Sweeris via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> So, I’m working on a type, and would like to make it conform to 
> `ExpressibleByArrayLiteral`. The thing is, I don’t actually care what type 
> `Element` is as long as it conforms to `FixedWidthInteger` and 
> `UnsignedInteger`. I tried writing this:
>   public init  (arrayLiteral 
> elements: U...) { … }
> But Xcode says my type doesn’t conform to `ExpressibleByArrayLiteral` unless 
> I add an init that takes a concrete type:
>   public init(arrayLiteral elements: UInt...) { … }
> 
> Does anyone else think the generic init should to be able to satisfy 
> `ExpressibleByArrayLiteral` (especially since `UInt` meets the conformance 
> requirements)?
> 
> Your type needs to be generic.

It already is… I just don’t want to restrict it to being initialized from array 
literals containing that same generic type.

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

[swift-evolution] Pitch: Allow generic functions to fulfill non-generic protocol requirements

[David Sweeris via swift-evolution]

So, I’m working on a type, and would like to make it conform to 
`ExpressibleByArrayLiteral`. The thing is, I don’t actually care what type 
`Element` is as long as it conforms to `FixedWidthInteger` and 
`UnsignedInteger`. I tried writing this:
  public init  (arrayLiteral elements: 
U...) { … }
But Xcode says my type doesn’t conform to `ExpressibleByArrayLiteral` unless I 
add an init that takes a concrete type:
  public init(arrayLiteral elements: UInt...) { … }

Does anyone else think the generic init should to be able to satisfy 
`ExpressibleByArrayLiteral` (especially since `UInt` meets the conformance 
requirements)? I suspect that the compiler is complaining because the generic 
init function implies that the `Element` associated type is a generic 
constraint, rather than a concrete type (which maybe makes this related to 
generic protocols?). I think that’s only an issue because of the current 
ExpressibleBy*Literal protocols’ reliance on associated types to specify the 
relevant init’s signature, though. If the protocols (or literal system) could 
be re-architected so they don't need those associated types, it might make 
implementing this easier. I don’t know how much work either approach would be. 
Nor am I sure if it’d be better for this to be a use-case for another proposal 
instead of its own thing.

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

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

[David Sweeris via swift-evolution]

> On May 12, 2017, at 19:29, Ben Cohen via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of revisions to SE-0176: Enforce Exclusive Access to Memory begins 
> now and runs through May 17, 2017.
> 
> Most of this proposal was previously accepted.  An implementation issue has 
> been discovered with the use of dynamic enforcement on inout parameters.  The 
> proposal implementors suggest adopting a stronger rule governing the use of 
> non-escaping closures which will also allow Swift to make firm guarantees 
> about the use of static enforcement when a variable does not escape.  The 
> core team tentatively supports this new rule but believes it is a substantial 
> enough revision that it requires a separate review period.
> The proposal is available here: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
> 

This subject is a bit over my head, but from what I do understand, +1

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0179: Swift `run` Command

[David Sweeris via swift-evolution]

> On May 15, 2017, at 5:09 PM, Daniel Dunbar  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0179: Swift `run` Command begins now and runs through May 
> 25th, 2017.
> 
> The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0179-swift-run-command.md
>  
> 
> 
> What is your evaluation of the proposal?

+1
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Sure
> Does this proposal fit well with the feel and direction of Swift?
Yes
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
N/A
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
I read the proposal and couple times.

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