Re: [swift-evolution] [swift 4] static libs/modular code, fixed-size arrays, ref/pointer to structs, pointers, numeric types.

[Chris Lattner via swift-evolution]

On Aug 3, 2016, at 11:11 AM, Raphael Sebbe via swift-evolution 
 wrote:
> Heard about the Swift 4 thing, so here are a few thoughts about the current 
> version of Swift (3). We work on a sizeable code base, with a focus on 
> modular code that is shared across our apps. Sorry if these things have been 
> discussed already, just joined, and wanted to share a snapshot of our 
> experience.

This is great, thanks!  Almost all of this are out of scope for Swift 4 stage 
1, but this is great feedback.  Here are some comments from me, not speaking 
for the core team:

> 1. Swift is very good for lots of stuff. My favorite is code clarity and 
> conciseness. Math code is great in Swift too (where I typically used Obj-C++ 
> previously). I can feel the potential of development going faster and code 
> getting safer at the same time. Love it.

Great!

> 2. Need for static libraries (or equivalent): let me give you an example of 
> how we organize our code. We have an image processing library, XXX, which 
> currently has 2 backends : XXX+Metal XXX+OpenGL. Orthogonal to that, another 
> extension allows JPEG file export using a third-party encoder, XXX+JPEG. 
> Another feature, for when we need to process video buffer, XXX+CoreVideo 
> which provides handling of native pixelbuffer. All of these are curently made 
> as static libraries (5 libs for XXX and extensions) that can be linked into 
> the app depending whether they are needed or not. Framework could technically 
> be used too, but that is both inefficient (why link the code at runtime? 
> Launch delay, etc.) and it does not scale (we'd need 20 frameworks to build a 
> single app).

Makes sense.  This is something that I’d personally like SwiftPM to explore.  
There is no specific reason that each swift package needs to be its own dylib.  
I know the SwiftPM team is aware of this, and maybe there will be time to 
tackle it over the next year.

> 3. Fixed-size Arrays are missing. They are useful in some contexts like:
> struct Quad { CGPoint corners[4]; }
> using a let array makes values immutable, using a var Array makes array 
> *size* mutable, which is not what is needed here. 

Yep, as James mentioned, this is sort-of handled with tuples today, but not 
satisfactorily (for a lot of reasons).  We should do better here.

> 4. Reference/pointer to structs: accessing & modifying structs deep into the 
> model currently requires fully qualified path to the struct instance. Fully 
> qualifying an inner struct in your data model can be very tedious, depending 
> on model complexity. 

The memory ownership work that is part of Swift 4 stage 1 may improve this 
situation, by introducing the notion of mutable references.  We’ll have to see 
how that works out.

> 5. Memory / pointer access, including casting. It's too verbose currently IMO 
> when compared to C. Should be better supported for a language that is also 
> targeting low-level (network, disk storage). A syntax that is both fast (like 
> C) and safe would be great.
> 6. Explicit casting between numeric types (CGFloat / Double / etc.) are 
> cumbersome, or Int and float types. Some kind of auto promotion would be nice.

Both of these are similar, I personally completely agree that we should have 
the ability to have “small fp” promote to “bigger fp” types.  This could be 
modeled by being able to define subtype relationships between structs.

> 7. I'm also fan of async/await kind of stuff, asynchronous flows, etc., but 
> this has already been mentioned -> cool!

Me too, I can’t wait to get there, but we have to stay focused :-)

-Chris

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

Re: [swift-evolution] Improved value and move semantics

[Chris Lattner via swift-evolution]

On Aug 3, 2016, at 7:57 PM, Joe Groff  wrote:
 
 a. We indirect automatically based on some heuristic, as an
 optimization.
>> 
>> I weakly disagree with this, because it is important that we provide a 
>> predictable model.  I’d rather the user get what they write, and tell people 
>> to write ‘indirect’ as a performance tuning option.  “Too magic” is bad.
> 
> I think 'indirect' structs with a heuristic default are important to the way 
> people are writing Swift in practice. We've seen many users fully invest in 
> value semantics types, because they wants the benefits of isolated state, 
> without appreciating the code size and performance impacts. Furthermore, 
> implementing 'indirect' by hand is a lot of boilerplate. Putting indirectness 
> entirely in users' hands feels to me a lot like the "value if word sized, 
> const& if struct" heuristics C++ makes you internalize, since there are 
> similar heuristics where 'indirect' is almost always a win in Swift too.

I understand with much of your motivation, but I still disagree with your 
conclusion.  I see this as exactly analogous to the situation and discussion 
when we added indirect to enums.  At the time, some argued for a magic model 
where the compiler figured out what to do in the most common “obvious” cases.  

We agreed to use our current model though because:
1) Better to be explicit about allocations & indirection that implicit.  
2) The compiler can guide the user in the “obvious” case to add the keyword 
with a fixit, preserving the discoverability / ease of use.
3) When indirection is necessary, there are choices to make about where the 
best place to do it is.
4) In the most common case, the “boilerplate” is a single “indirect” keyword 
added to the enum decl itself.  In the less common case, you want the 
“boilerplate” so that you know where the indirections are happening.

Overall, I think this model has worked well for enums and I’m still very happy 
with it.  If you generalize it to structs, you also have to consider that this 
should be part of a larger model that includes better support for COW.  I think 
it would be really unfortunate to “magically indirect” struct, when the right 
answer may actually be to COW them instead.  I’d rather have a model where 
someone can use:

// simple, predictable, always inline, slow in some cases.
struct S1 { … }  

And then upgrade to one of:

indirect struct S2 {…}
cow struct S3 { … } 

Depending on the structure of their data.  In any case, to reiterate, this 
really isn’t the time to have this debate, since it is clearly outside of stage 
1.

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

Re: [swift-evolution] ExpressibleByStringInterpolation vs. String re-evaluation vs. Regex

[Jacob Bandes-Storch via swift-evolution]

Here's another example use case: Auto Layout visual format strings.

https://gist.github.com/jtbandes/9c1c25ee4996d2554375#file-constraintcollection-swift-L85-L87

Since only views and numeric types are supported, the generic init has
to be a run-time error. Ideally it could be a compile-time error.

On Tue, Aug 2, 2016 at 6:10 PM, Brent Royal-Gordon 
wrote:

> > On Jul 30, 2016, at 10:35 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > In the past, there has been some interest in refining the behavior of
> ExpressibleByStringInterpolation (née StringInterpolationConvertible), for
> example:
> >
> > - Ability to restrict the types that can be used as interpolation
> segments
> > - Ability to distinguish the string-literal segments from interpolation
> segments whose type is String
> >
> > Some prior discussions:
> > - "StringInterpolationConvertible and StringLiteralConvertible
> inheritance"
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/017654.html
> > - Sub-discussion in "Allow multiple conformances to the same protocol"
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160606/020746.html
> > - "StringInterpolationConvertible: can't distinguish between literal
> components and String arguments"  https://bugs.swift.org/browse/SR-1260 /
> rdar://problem/19800456&18681780
> > - "Proposal: Deprecate optionals in string interpolation"
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018000.html
> >
> >
> > About Swift 4, Chris wrote:
> >  - String re-evaluation: String is one of the most important fundamental
> types in the language.  The standard library leads have numerous ideas of
> how to improve the programming model for it, without jeopardizing the goals
> of providing a unicode-correct-by-default model.  Our goal is to be better
> at string processing than Perl!
> >
> > I'd be interested in any more detail the team can provide on this. I'd
> like to talk about string interpolation improvements, but it wouldn't be
> wise to do so without keeping an eye towards possible regex/pattern-binding
> syntax, and the String refinements that the stdlib team has in mind, if
> there's a chance they would affect interpolation.
> >
> > Discuss!
>
> I'm not one of the core team, so all I can really provide is a use case.
>
> Given a LocalizedString type like:
>
> /// Conforming types can be included in a LocalizedString.
> protocol LocalizedStringConvertible {
> /// The format to use for this instance. This format string will
> be included in the key when
> /// this type is interpolated into a LocalizedString.
> var localizedStringFormat: String { get }
>
> /// The arguments to use when formatting to represent this
> instance.
> var localizedStringArguments: [CVarArg] { get }
> }
>
> extension NSString: LocalizedStringConvertible {…}
> extension String: LocalizedStringConvertible {…}
> extension LocalizedString: LocalizedStringConvertible {…}
>
> extension Int: LocalizedStringConvertible {…}
> // etc.
>
> struct LocalizedString {
> /// Initializes a LocalizedString by applying the `arguments` to
> the format string with the
> /// indicated `key` using `String.init(format:arguments:)`.
> ///
> /// If the `key` does not exist in the localized string file, the
> `key` itself will be used as
> /// the format string.
> init(key: String, formattedWith arguments: [CVarArg]) {…}
> }
>
> extension String {
> init(_ localizedString: LocalizedString) {
> self.init(describing: localizedString)
> }
> }
>
> extension LocalizedString {
> /// Initializes a LocalizedString with no arguments which uses the
> indicated `key`. `%`
> /// characters in the `key` will be converted to `%%`.
> ///
> /// If the `key` does not exist in the localized string file, the
> `key` itself will be used as
> /// the string.
> init(key: String) {…}
>
> /// Initializes a LocalizedString to represent the indicated
> `value`.
> init(_ value: LocalizedStringConvertible) {…}
>
> /// Initializes a LocalizedString to represent the empty string.
> init() {…}
> }
>
> extension LocalizedString: CustomStringConvertible {…}
>
> extension LocalizedString: ExpressibleByStringLiteral {
> init(stringLiteral value: String) {
> self.init(key: value)
> }
> …
> }
>
> The current ExpressibleByStringInterpolation protocol has a number of
> defects.
>
> 1. We want to only permit LocalizedStringConvertible types, or at
> least *use* the LocalizedStringConvertible conformance; neither of these
> appears to be possible. (`is` and `as?` casts always fail, overloads don't
> seem to be called, etc.)
>
> 2. The literal parts of the string are 

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Brandon Knope via swift-evolution]

Using Apple Developer Forums would cause people to leave swift-evolution (a 
prediction). I don’t think they offer a good enough experience for quick 
discussions like mailing lists or Discourse do.

My question is: would we gain more people than we would lose in moving over to 
something like Discourse?

I don’t think a lot of people on here are grasping the high burden mailing 
lists place on people not familiar with them

Brandon

> On Aug 3, 2016, at 10:02 PM, Paulo Faria via swift-evolution 
>  wrote:
> 
> Exactly what I was going to say. Why not use Apple’s forum?
> It’s there already. It’s just a matter of using it. Some are saying things 
> like, the core team should be focused on working on the language, etc. That’s 
> so obvious that it shouldn’t even be said. This is a fact, but a fact that 
> has nothing to do with having a good communication medium. It’s just a matter 
> of decision. The core team could decide we use apple’s forum instead of the 
> mailing list, boom, done. If we need any extra features from the forum, it’s 
> not gonna be the core team to deal with. It will be the people that are 
> already responsible for the apple forum.
> 
>> On Aug 3, 2016, at 6:47 AM, David Hart via swift-evolution 
>> > wrote:
>> 
>> I did not have the time to counter all those points but I was going to and 
>> point that Discourse has a solution for nearly all of those. I would REALLY 
>> prefer having the mailing-list part of the discussion on Discourse.
>> 
>>> On 03 Aug 2016, at 07:46, Jacob Bandes-Storch via swift-evolution 
>>> > wrote:
>>> 
>>> I hope my replies aren't too curt — I don't want to pick a fight (any more 
>>> than I did by starting this topic), but to explore how Discourse can serve 
>>> these use cases. Feel free to re-rebut.
>>> 
>>> On Mon, Aug 1, 2016 at 3:03 PM, Brent Royal-Gordon >> > wrote:
>>> 
>>> I don't think enough has been said in favor of mailing lists. Some 
>>> advantages for them:
>>> 
>>> 1. Available on every platform.
>>> Browsers too.
>>>  
>>> 
>>> 2. Performant on every platform. (Discourse, for instance, struggles on 
>>> Android.)
>>> Browsers are heavily tuned for performance, and Discourse is a relatively 
>>> lightweight site. If you prefer the performance of your email client, 
>>> there's mailing list mode.
>>> 
>>> 
>>> 3. Native on every platform.
>>> Browsers too.
>>>  
>>> 
>>> 4. Based on open standards with multiple implementations.
>>> Browsers too. You may argue that the forum itself is too centralized, but 
>>> Mailman is necessarily centralized too.
>>> 
>>> And this isn't always a positive: formatting of styled, quoted, and even 
>>> plain text is quite varied among email clients, so popular threads often 
>>> end up looking like huge messes.
>>>  
>>> 
>>> 5. Does not require you to proactively check swift-evolution.
>>> Email notification settings, or full-on mailing list mode, or RSS, can 
>>> solve this.
>>> 
>>> 
>>> 6. Supports offline reading and drafting.
>>> Mailing list mode or RSS / reply-by-email.
>>> 
>>> 
>>> 7. Supports clients with alternate feature sets.
>>> Discourse has RSS feeds and JSON APIs.
>>>  
>>> 
>>> 8. Supports bot clients for both sending (like the CI bot) and receiving 
>>> (like Gmane).
>>> Discourse has an API 
>>>  which can 
>>> be used for posting. It also supports bot-like plugins 
>>>  which can 
>>> respond to various events, although I imagine that requires self-hosting. 
>>> External bots interested in receiving would probably need to poll RSS, or 
>>> just make use of mailing list mode as a receive hook.
>>> 
>>> 
>>> 9. Supports user-specific automatic filtering.
>>> Topics and categories in Discourse each support a range of notification 
>>> options from "watching" to "muted". My understanding is that these settings 
>>> are respected by mailing list mode.
>>>  
>>> 
>>> 10. Users can privately annotate messages.
>>> Discourse has "bookmarks", basically a way of saving individual 
>>> posts/replies for yourself. Users can also send themselves private messages 
>>> 
>>>  for note-taking purposes.
>>>  
>>> 
>>> 11. Drafts and private messages are not visible to any central 
>>> administrator.
>>> I'm not sure whether Discourse drafts are saved on the server. Moderators 
>>> are restricted from viewing private messages 
>>> .
>>>  Of course, you can always contact someone via other means.
>>> 
>>> 
>>> 12. History is stored in a distributed fashion; there is no single point of 
>>> failure that could wipe out 

Re: [swift-evolution] [META] Gmane and Swift Evolution

[Saagar Jha via swift-evolution]

I’ve submitted a pull that includes everything except for SE-0094, 0095, and 
0110, which I wasn’t able to find.

Saagar Jha



> On Aug 3, 2016, at 11:31, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Aug 2, 2016, at 9:22 AM, Ben Rimmington  wrote:
>> 
>> 
>>> On 2 Aug 2016, at 16:16, Erica Sadun via swift-evolution 
>>>  wrote:
>>> 
>>> Anyone willing to adopt a proposal or a group and get them updated, please 
>>> reply in-thread and submit a PR with changes.
>> 
>> [SE-0076 ... SE-0090] 
>> 
>> -- Ben
>> 
> 
> Here's what's left
> 
> proposals/0092-typealiases-in-protocols.md:* Status: **Implemented in Swift 
> 3.0** 
> ([Rationale](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17317))
> proposals/0094-sequence-function.md:Swift-evolution thread: [Discussion 
> thread topic for that 
> proposal](http://thread.gmane.org/gmane.comp.lang.swift.evolution/15743/focus=17108)
> proposals/0094-sequence-function.md:[SE-0045a]: 
> http://article.gmane.org/gmane.comp.lang.swift.evolution/16119
> proposals/0095-any-as-existential.md:Discussion threads: 
> [pre-proposal](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018109.html),
>  [review thread 
> 1](http://thread.gmane.org/gmane.comp.lang.swift.evolution/18349), 
> [2](http://thread.gmane.org/gmane.comp.lang.swift.evolution/18350/focus=18447),
>  
> [3](http://thread.gmane.org/gmane.comp.lang.swift.evolution/18351/focus=18440),
>  [4](http://thread.gmane.org/gmane.comp.lang.swift.evolution/18518), 
> [post-review 
> thread](http://thread.gmane.org/gmane.comp.lang.swift.evolution/19463)
> proposals/0096-dynamictype.md:[RFC: didset and 
> willset](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17534)
> proposals/0097-negative-attributes.md:[RFC: didset and 
> willset](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17534)
> proposals/0098-didset-capitalization.md:[RFC: didset and 
> willset](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17534)
> proposals/0099-conditionclauses.md:[\[Pitch\] making where and ,  
> interchangeable in guard 
> conditions](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17926)
> proposals/0101-standardizing-sizeof-naming.md:* Swift Evolution Pitch: 
> [\[Pitch\] Renaming sizeof, sizeofValue, strideof, 
> strideofValue](http://thread.gmane.org/gmane.comp.lang.swift.evolution/19459)
> proposals/0101-standardizing-sizeof-naming.md:* [Earlier 
> Discussions](http://thread.gmane.org/gmane.comp.lang.swift.evolution/15830)
> proposals/0101-standardizing-sizeof-naming.md:* [SE-0101 
> Review](http://thread.gmane.org/gmane.comp.lang.swift.evolution/21103)
> proposals/0103-make-noescape-default.md:* [Make non-escaping closures the 
> default](http://thread.gmane.org/gmane.comp.lang.swift.evolution/19756)
> proposals/0105-remove-where-from-forin-loops.md:Swift Evolution Discussion: 
> [\[Pitch\] Retiring `where` from for-in 
> loops](http://thread.gmane.org/gmane.comp.lang.swift.evolution/20142)
> proposals/0106-rename-osx-to-macos.md:Swift Evolution Discussion: [\[DRAFT\] 
> Aliasing the OS X Platform Configuration 
> Test](http://thread.gmane.org/gmane.comp.lang.swift.evolution/20815)
> proposals/0108-remove-assoctype-inference.md:swift-evolution thread: 
> [pre-proposal](http://thread.gmane.org/gmane.comp.lang.swift.evolution/21714)
> proposals/0108-remove-assoctype-inference.md:As Douglas Gregor (original 
> author of the relevant type inference code) [puts 
> it](http://article.gmane.org/gmane.comp.lang.swift.evolution/22058):
> proposals/0108-remove-assoctype-inference.md:To some extent, this is an issue 
> inherent to any design which makes no distinctions at the site of 
> implementation between members intended to satisfy protocol requirements and 
> members that are explicitly not intended to satisfy protocol requirements. 
> Rather than adding keywords to create this distinction, Douglas Gregor has 
> [proposed and implemented type checker 
> heuristics](http://article.gmane.org/gmane.comp.lang.swift.devel/1799) that 
> will generate warnings when a programmer implements a member that "looks 
> like" it should fulfill a protocol requirement but does not actually do so. 
> This is one possible mitigation strategy that should be revisited as a way to 
> decrease the possible impact of removing associated type witness inference 
> from the compiler.
> proposals/0108-remove-assoctype-inference.md:As well, Dave Abrahams expresses 
> a [potential 
> issue](http://article.gmane.org/gmane.comp.lang.swift.evolution/21892):
> proposals/0109-remove-boolean.md:* Status: Accepted 
> ([Rationale](http://thread.gmane.org/gmane.comp.lang.swift.evolution/23844))
> proposals/0109-remove-boolean.md:[Discussion 
> thread](http://thread.gmane.org/gmane.comp.lang.swift.evolution/21559)
> 

Re: [swift-evolution] Improved value and move semantics

[Joe Groff via swift-evolution]

> On Aug 3, 2016, at 4:58 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> On Aug 3, 2016, at 6:41 AM, Matthew Johnson via swift-evolution 
>  wrote:
 Then you can just slap `indirect` on a struct whose copying is too
 complicated and let Swift transparently COW it for you. (And it would
 also permit recursive structs and other such niceties.)
>>> 
>>> My vision for this feature is:
>>> 
>>> a. We indirect automatically based on some heuristic, as an
>>> optimization.
> 
> I weakly disagree with this, because it is important that we provide a 
> predictable model.  I’d rather the user get what they write, and tell people 
> to write ‘indirect’ as a performance tuning option.  “Too magic” is bad.

I think 'indirect' structs with a heuristic default are important to the way 
people are writing Swift in practice. We've seen many users fully invest in 
value semantics types, because they wants the benefits of isolated state, 
without appreciating the code size and performance impacts. Furthermore, 
implementing 'indirect' by hand is a lot of boilerplate. Putting indirectness 
entirely in users' hands feels to me a lot like the "value if word sized, 
const& if struct" heuristics C++ makes you internalize, since there are similar 
heuristics where 'indirect' is almost always a win in Swift too.

-Joe

>>> b. We allow you to indirect manually.
>>> 
>>> c. We provide an attribute that suppresses automatic indirection to
>>> whatever depth possible given resilience boundaries.
>> 
>> This all sounds great.  Does any of this fit into Swift 4 (either phase 1 or 
>> phase 2)?  It seems like at least the automatic part would have ABI impact.
> 
> This is very low priority, because it is generally additive. After the major 
> topics for ABI stability are figured out, we can have the philosophic 
> discussion about the automatic part.
> 
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] MemoryLayout for a value

[Xiaodi Wu via swift-evolution]

On Wed, Aug 3, 2016 at 8:47 PM, Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

> > On Aug 3, 2016, at 2:43 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> > Having seen the effects in the standard library and in other
> > code, I'm concerned that we may have made a mistake in removing
> > `sizeofValue` et al without providing a replacement.  In the standard
> > library, we ended up adding an underscored API that allows
> >
> >  MemoryLayout._ofInstance(someExpression).size
> >
> > Where someExpression is an autoclosure, and thus not evaluated.  I
> > wanted to bring up the possibility of introducing a replacement as a
> > bufix.
> >
> > I propose that the way to express the above should be:
> >
> >  MemoryLayout.of(type(of: someExpression)).size
> >
> > implementable as:
> >
> >  extension MemoryLayout {
> >@_transparent
> >public
> >static func of(_: T.Type) -> MemoryLayout.Type {
> >  return MemoryLayout.self
> >}
> >  }
> >
> > I think this API would solve the concerns I had about confusability that
> > led me to advocate dropping the ability to ask for the size of a value.
> > The only way to use it is to pass a type and these two expressions have
> > equivalent meaning:
> >
> >MemoryLayout
> >MemoryLayout.of(Int.self)
> >
> > It also has the benefit of isolating the autoclosure magic to type(of:).
> >
> > ,[ Aside ]
> > | A slightly cleaner use site is possible with a larger API change:
> > |
> > |   MemoryLayout(type(of: someExpression)).size
> > |
> > | Which would involve changing MemoryLayout from an `enum` to
> > | a `struct` and adding the following:
> > |
> > |   extension MemoryLayout {
> > | public init(_: T.Type) {}
> > |
> > | public var size: Int { return MemoryLayout.size }
> > | public var stride: Int { return MemoryLayout.stride }
> > | public var alignment: Int { return MemoryLayout.alignment }
> > |   }
> > |
> > | However I am concerned that dropping ".of" at the use site is worth the
> > | added API complexity.
> > `
> >
> > Thoughts?
> > --
> > -Dave
>
>
> I don't think using "of" is a great burden.
>

Agreed, but I do think "memory layout of type of my value, size" is a
mouthful compared to "size of value". Moreover, something doesn't sit right
with me that MemoryLayout and MemoryLayout.of(T.self) would be one and
the same thing.

Could I suggest an alternative? It's conservative in that it mimics the
relationships we had before the proposal was implemented and also maintains
the simplicity of the caseless enum:

```
extension MemoryLayout {
  static func size(ofValue _: T) -> Int { return MemoryLayout.size }
  // etc.
}
```


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

Re: [swift-evolution] [Swift 4.0] Conditional conformances via protocol extensions

[Brent Royal-Gordon via swift-evolution]

> On Aug 3, 2016, at 10:17 AM, Manav Gabhawala via swift-evolution 
>  wrote:
> 
> I was wondering why this would put any more of a burden on the runtime
> than simple inheritance of protocols. The way this could be
> implemented is to augment the ConformanceTable for nominal types by
> looking up its protocol extension’s inheritance clauses. I can
> definitely see this impacting compile time but I don’t see why runtime
> performance will be any different than simple inheritance. Further,
> cyclic chains can be detected and broken (compiler error) during the
> second pass of semantic analysis.

My understanding—which may be incorrect, by the way—is that the issue is mainly 
with protocol extensions adding conformances, not specifically with those 
conformances being conditional, and that it specifically has to do with `is` 
and `as?` checks across module boundaries.

Suppose you have these declarations in module M:

public protocol AProtocol {…}
public protocol BProtocol: AProtocol {…}
public protocol CProtocol {…}

// Public or otherwise doesn't matter here.
public struct Foo: BProtocol {…}

Foo essentially has a flat list of the protocols it conforms to attached to it. 
Notionally, you can think of that list as looking like:

Foo.self.conformsTo = [BProtocol.self, AProtocol.self]

And when you write `foo is CProtocol`, that eventually translates into:

foo.dynamicType.conformsTo.contains(CProtocol.self)

For a `Foo`, since the `conformsTo` list doesn't include `CProtocol.self`, it 
returns `false`.

Now imagine that you write a new module, N, and in it you say:

extension Foo: CProtocol {…}

You have now retroactively conformed `Foo` to `CProtocol`. Swift needs to reach 
into module M and add `CProtocol.self` to the `Foo.self.conformsTo` list. This 
is perfectly doable for a concrete type—it's one flat list, after all.

Instead, though, imagine that module N extended `AProtocol` to add a 
conformance:

extension AProtocol: CProtocol {…}

There are two ways to handle this. One is to find all types conforming to 
`AProtocol`, recursively, and add `CProtocol.self` to their conformance list. 
The other is to scrap the flat list of conformances and instead make `is` and 
`as?` recursively search each protocol. Either way, you have replaced a fast, 
flat operation with a slow, recursive one.

Conditional conformance adds another wrinkle to this, of course—you must not 
only recursively search the list, but also evaluate the condition to see if it 
applies in this case. But the general problem of having to replace a fast 
search with a slow search applies either way.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Paulo Faria via swift-evolution]

Exactly what I was going to say. Why not use Apple’s forum?
It’s there already. It’s just a matter of using it. Some are saying things 
like, the core team should be focused on working on the language, etc. That’s 
so obvious that it shouldn’t even be said. This is a fact, but a fact that has 
nothing to do with having a good communication medium. It’s just a matter of 
decision. The core team could decide we use apple’s forum instead of the 
mailing list, boom, done. If we need any extra features from the forum, it’s 
not gonna be the core team to deal with. It will be the people that are already 
responsible for the apple forum.

> On Aug 3, 2016, at 6:47 AM, David Hart via swift-evolution 
>  wrote:
> 
> I did not have the time to counter all those points but I was going to and 
> point that Discourse has a solution for nearly all of those. I would REALLY 
> prefer having the mailing-list part of the discussion on Discourse.
> 
>> On 03 Aug 2016, at 07:46, Jacob Bandes-Storch via swift-evolution 
>> > wrote:
>> 
>> I hope my replies aren't too curt — I don't want to pick a fight (any more 
>> than I did by starting this topic), but to explore how Discourse can serve 
>> these use cases. Feel free to re-rebut.
>> 
>> On Mon, Aug 1, 2016 at 3:03 PM, Brent Royal-Gordon > > wrote:
>> 
>> I don't think enough has been said in favor of mailing lists. Some 
>> advantages for them:
>> 
>> 1. Available on every platform.
>> Browsers too.
>>  
>> 
>> 2. Performant on every platform. (Discourse, for instance, struggles on 
>> Android.)
>> Browsers are heavily tuned for performance, and Discourse is a relatively 
>> lightweight site. If you prefer the performance of your email client, 
>> there's mailing list mode.
>> 
>> 
>> 3. Native on every platform.
>> Browsers too.
>>  
>> 
>> 4. Based on open standards with multiple implementations.
>> Browsers too. You may argue that the forum itself is too centralized, but 
>> Mailman is necessarily centralized too.
>> 
>> And this isn't always a positive: formatting of styled, quoted, and even 
>> plain text is quite varied among email clients, so popular threads often end 
>> up looking like huge messes.
>>  
>> 
>> 5. Does not require you to proactively check swift-evolution.
>> Email notification settings, or full-on mailing list mode, or RSS, can solve 
>> this.
>> 
>> 
>> 6. Supports offline reading and drafting.
>> Mailing list mode or RSS / reply-by-email.
>> 
>> 
>> 7. Supports clients with alternate feature sets.
>> Discourse has RSS feeds and JSON APIs.
>>  
>> 
>> 8. Supports bot clients for both sending (like the CI bot) and receiving 
>> (like Gmane).
>> Discourse has an API 
>>  which can 
>> be used for posting. It also supports bot-like plugins 
>>  which can 
>> respond to various events, although I imagine that requires self-hosting. 
>> External bots interested in receiving would probably need to poll RSS, or 
>> just make use of mailing list mode as a receive hook.
>> 
>> 
>> 9. Supports user-specific automatic filtering.
>> Topics and categories in Discourse each support a range of notification 
>> options from "watching" to "muted". My understanding is that these settings 
>> are respected by mailing list mode.
>>  
>> 
>> 10. Users can privately annotate messages.
>> Discourse has "bookmarks", basically a way of saving individual 
>> posts/replies for yourself. Users can also send themselves private messages 
>> 
>>  for note-taking purposes.
>>  
>> 
>> 11. Drafts and private messages are not visible to any central administrator.
>> I'm not sure whether Discourse drafts are saved on the server. Moderators 
>> are restricted from viewing private messages 
>> .
>>  Of course, you can always contact someone via other means.
>> 
>> 
>> 12. History is stored in a distributed fashion; there is no single point of 
>> failure that could wipe out swift-evolution's history.
>> This is a fair point. But: 
>> - The Git repository of proposals is distributed.
>> - Discourse is as easily backed up as any other computer system: 
>> https://meta.discourse.org/t/configure-automatic-backups-for-discourse/14855 
>> 
>> - Users who would like a low-fidelity local copy for themselves can enable 
>> mailing list mode.
>> - Anyone is free to access/archive publicly accessible content using the 
>> APIs.
>>  
>> 
>> 13. Usually the medium of choice for large-scale, long-running open source 
>> projects.
>> 
>> Is that just because people already know how to use email? Is it 

Re: [swift-evolution] [swift 4] static libs/modular code, fixed-size arrays, ref/pointer to structs, pointers, numeric types.

[James Froggatt via swift-evolution]

You make some interesting points. My feedback's inline.

> 1. Swift is very good for lots of stuff. My favorite is code clarity and 
> conciseness. Math code is great in Swift too (where I typically used Obj-C++ 
> previously). I can feel the potential of development going faster and code 
> getting safer at the same time. Love it.

Same. Another one of my favourites is optionals, and non-nullable references by 
default.

> 2. Need for static libraries (or equivalent): let me give you an example of 
> how we organize our code. We have an image processing library, XXX, which 
> currently has 2 backends : XXX+Metal XXX+OpenGL. Orthogonal to that, another 
> extension allows JPEG file export using a third-party encoder, XXX+JPEG. 
> Another feature, for when we need to process video buffer, XXX+CoreVideo 
> which provides handling of native pixelbuffer. All of these are curently made 
> as static libraries (5 libs for XXX and extensions) that can be linked into 
> the app depending whether they are needed or not. Framework could technically 
> be used too, but that is both inefficient (why link the code at runtime? 
> Launch delay, etc.) and it does not scale (we'd need 20 frameworks to build a 
> single app).
> 
> Swift, with its extension concept, is very well suited to modular development 
> like this. We'd like to have a better option than frameworks to build 
> reusable libraries. It's not an ABI thing, we really don't care about that, 
> we use libs just to organize code, building them as a part of the app, and 
> *not* to provide precompiled libraries to some other developers. Swift 
> package manager does not work well within Xcode either at this time, and has 
> a number of constraints we don't want (like having a separate git repo for 
> each static lib -> that's not practical at all if you just have 1 or 2 files 
> in that lib).
> 
> I met 4 people at WWDC from both Swift and Xcode teams, but I'm not sure this 
> topic went through. This is a major concern: organizing reusable code 
> efficiently is what will bring Swift into larger projects where it could 
> really shine. We're currently using a hack to enable modular development in 
> Swift (static libs), and that should be addressed as fast as possible, all 
> languages have that, we shouldn't wait for Swift 5 or 6 to get it. This is by 
> far our number one concern with Swift.

Agreed. Frameworks really aren't enough.

> 3. Fixed-size Arrays are missing. They are useful in some contexts like:
> struct Quad { CGPoint corners[4]; }
> using a let array makes values immutable, using a var Array makes array 
> *size* mutable, which is not what is needed here. 

What are your thoughts on using tuples for this? 

typealias CGPoint4 = (CGPoint, CGPoint, CGPoint, CGPoint)

struct Quad { var corners: CGPoint4 }

var fixedLength = (point1, point2, point3, point4)
print(fixedLength.0)
print(fixedLength.4) //compiler error, not an element of the tuple

With shorthand declaration syntax, this would have the benefits of a 
fixed-length array with added compile-time safety. A previously suggested 
syntax was along the lines of '(CGPoint * 4)'.

> 4. Reference/pointer to structs: accessing & modifying structs deep into the 
> model currently requires fully qualified path to the struct instance. Fully 
> qualifying an inner struct in your data model can be very tedious, depending 
> on model complexity. 
>  
> For instance, with scoped access solutions made with Swift 3, you need to 
> cascade blocks if you need to access multiple inner structs, which doesn't 
> scale well as it creates code pyramids:
> 
> scopedAccess() {  
>  scopedAccess() {  
>   // modify varA & varB  
>  }  
> }
>   
> It's easily done in C/C++ using pointers/references. To make that better, 
> we'd need some kind of language support IMO.

Could this be generalised, maybe with a reference-semantic ‘property accessor’?

Example:

let get: () -> Bool = #get(controller.view.isVisible)
print(get())

let set: (Bool) -> () = #set(controller.view.isVisible)
set(true)

let accessor: Lens = #lens(controller.view.isVisible)
print(accessor.value)
accessor.value = true

This would have the added bonus of also tracking the reassignment of 
reference-type properties - in this example, if 'view' is reassigned, the 
referenced value is updated.

> 5. Memory / pointer access, including casting. It's too verbose currently IMO 
> when compared to C. Should be better supported for a language that is also 
> targeting low-level (network, disk storage). A syntax that is both fast (like 
> C) and safe would be great.

Not familiar with low-level programming in Swift, but have you considered 
creating domain-specific operators?
For example, I imagine something like 'UnsafeMutablePointer(v)' could be 
reduced to '*v'.

> 6. Explicit casting between numeric types (CGFloat / Double / etc.) are 
> cumbersome, or Int and float types. Some kind of auto promotion would be nice.

I think Swift generally 

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Charles Srstka via swift-evolution]

> On Aug 3, 2016, at 4:11 PM, David Owens II via swift-evolution 
>  wrote:
> 
> But does it already surpass the limits?
> 
>>  • There is a bandwidth limit of 100k monthly page views, equivalent to 
>> our Standard hosting plan.
>>  • If you exceed our bandwidth limit – which is very unlikely, unless 
>> your project is enormous – you have two options:
>>  • We’ll help you move to self-hosting, either on your own 
>> server or any Docker compatible cloud (a $20/month Digital Ocean droplet 
>> should suffice).
>>  • Upgrade to our Business hosting plan at 50% off.
> 
> I wouldn’t be surprised if it’s close if not passed 100k monthly views 
> already. 
> 
> The big unknown is also around the mailing list support. Is it super robust 
> and work as well for communicating as the mailing currently does? I don’t 
> know. I’ve not been involved with large projects on discourse.

Apple has a lot of money; I doubt being unable to go with the free option would 
be a big dealbreaker.

It should probably be mentioned, though, that Apple already has a developer 
forum set up, and a server to run it on, and everything. Is there any reason 
they couldn’t just use that?

Charles

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

Re: [swift-evolution] MemoryLayout for a value

[Xiaodi Wu via swift-evolution]

Why not just MemoryLayout.init(of instance: T), and drop the autoclosure
magic altogether?

The classic sizeofValue evaluated its argument, and in Foundation several
uses of it actually relied on that side effect. While autoclosures are
quite clever, in general I think the user expectation is that given
`a(b(c))` both a and b are invoked, side effects and all.

Note that both type(of:) as it's currently implemented and the old
dynamicType evaluate its argument/receiver. No one afaik has ever thought
that behavior to be anomalous (though I bet we're about to hear some
arguments to that effect now).
On Wed, Aug 3, 2016 at 15:46 Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> Having seen the effects in the standard library and in other
> code, I'm concerned that we may have made a mistake in removing
> `sizeofValue` et al without providing a replacement.  In the standard
> library, we ended up adding an underscored API that allows
>
>   MemoryLayout._ofInstance(someExpression).size
>
> Where someExpression is an autoclosure, and thus not evaluated.  I
> wanted to bring up the possibility of introducing a replacement as a
> bufix.
>
> I propose that the way to express the above should be:
>
>   MemoryLayout.of(type(of: someExpression)).size
>
> implementable as:
>
>   extension MemoryLayout {
> @_transparent
> public
> static func of(_: T.Type) -> MemoryLayout.Type {
>   return MemoryLayout.self
> }
>   }
>
> I think this API would solve the concerns I had about confusability that
> led me to advocate dropping the ability to ask for the size of a value.
> The only way to use it is to pass a type and these two expressions have
> equivalent meaning:
>
> MemoryLayout
> MemoryLayout.of(Int.self)
>
> It also has the benefit of isolating the autoclosure magic to type(of:).
>
> ,[ Aside ]
> | A slightly cleaner use site is possible with a larger API change:
> |
> |   MemoryLayout(type(of: someExpression)).size
> |
> | Which would involve changing MemoryLayout from an `enum` to
> | a `struct` and adding the following:
> |
> |   extension MemoryLayout {
> | public init(_: T.Type) {}
> |
> | public var size: Int { return MemoryLayout.size }
> | public var stride: Int { return MemoryLayout.stride }
> | public var alignment: Int { return MemoryLayout.alignment }
> |   }
> |
> | However I am concerned that dropping ".of" at the use site is worth the
> | added API complexity.
> `
>
> Thoughts?
> --
> -Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Improved value and move semantics

[Matthew Johnson via swift-evolution]

> On Aug 3, 2016, at 3:48 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Aug 03 2016, Matthew Johnson  wrote:
> 
>>> On Aug 2, 2016, at 4:54 PM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> on Tue Aug 02 2016, Brent Royal-Gordon  wrote:
>>> 
>> 
> On Aug 2, 2016, at 12:06 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> If it says that, it's... not quite right.  There are things we could do
> to make some value copies more optimal.  For example, any value type
> containing multiple class references—or multiple other value types (such
> as arrays or strings or dictionaries) that contain class references—will
> cost more to copy than a single class reference does.  At the cost of
> some allocation and indirection, we could reduce the copying cost of
> such values.  It's an optimization we've considered making, but haven't
> prioritized.  
> 
> You can put a CoW wrapper around your value to do it manually.  I hacked
> one up using ManagedBuffer for someone at WWDC but I don't seem to have
> saved the code, sadly.
 
 Slightly off-topic, but one day I would like to see `indirect` turned
 into a generalized COW feature:
 
 * `indirect` can only be applied to a value type (or at least to a
 type with `mutating` members, so reference types would have to gain
 those).
 * The value type is boxed in a reference type.
 * Any use of a mutating member (and thus, use of the setter) is
 guarded with `isKnownUniquelyReferenced` and a copy.
 * `indirect` can be applied to an enum case with a payload (the
 payload is boxed), a stored property (the value is boxed), or a type
 (the entire type is boxed).
 
 Then you can just slap `indirect` on a struct whose copying is too
 complicated and let Swift transparently COW it for you. (And it would
 also permit recursive structs and other such niceties.)
>>> 
>>> My vision for this feature is:
>>> 
>>> a. We indirect automatically based on some heuristic, as an
>>>  optimization.
>>> 
>>> b. We allow you to indirect manually.
>>> 
>>> c. We provide an attribute that suppresses automatic indirection to
>>>  whatever depth possible given resilience boundaries.
>> 
>> This all sounds great.  Does any of this fit into Swift 4 (either
>> phase 1 or phase 2)?  It seems like at least the automatic part would
>> have ABI impact.
> 
> Yes.  In principle, all of it has the potential to fit in Swift 4.  I'm
> not sure what will actually happen of course.

Of course. :)  

I asked mostly because I am wondering when it might be appropriate to start 
discussing these topics in more detail, and specifically if they fit into the 
first phase of Swift 4 whether we should start a thread now.

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

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

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[David Owens II via swift-evolution]

But does it already surpass the limits?

>   • There is a bandwidth limit of 100k monthly page views, equivalent to 
> our Standard hosting plan.
>   • If you exceed our bandwidth limit – which is very unlikely, unless 
> your project is enormous – you have two options:
>   • We’ll help you move to self-hosting, either on your own 
> server or any Docker compatible cloud (a $20/month Digital Ocean droplet 
> should suffice).
>   • Upgrade to our Business hosting plan at 50% off.

I wouldn’t be surprised if it’s close if not passed 100k monthly views already. 

The big unknown is also around the mailing list support. Is it super robust and 
work as well for communicating as the mailing currently does? I don’t know. 
I’ve not been involved with large projects on discourse.

-David

> On Aug 3, 2016, at 1:34 PM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> As I mentioned at the top of this thread, Discourse provides free hosting for 
> community-friendly open-source projects 
> 
>  which I suspect would include Swift. If not, that would indeed throw a 
> wrench in the idea.
> 
> On Wed, Aug 3, 2016 at 1:30 PM, Daniel Duan via swift-evolution 
> > wrote:
> I’d rather the core team work on the language, stdlib and the compiler. 
> Wouldn’t you agree?
> 
> > On Aug 3, 2016, at 12:59 PM, Brandon Knope via swift-evolution 
> > > wrote:
> >
> > I wasn't expecting someone else to do it! This would need to be supported 
> > by the core team 100%
> >
> > Brandon
> >
> >> On Aug 3, 2016, at 3:42 PM, David Owens II  >> > wrote:
> >>
> >>
> >>> On Aug 3, 2016, at 5:21 AM, Brandon Knope via swift-evolution 
> >>> > wrote:
> >>>
> >>> I still think it is worth doing a test to see how everyone likes it:
> >>
> >> Even if it is better, someone if going to have to either maintain the 
> >> server and install of discourse _or_ pay discourse to host it. Until 
> >> someone on the core team agrees to those terms, what’s the point really?
> >>
> >> Has anyone looked into the possibility of extending discourse’ mail 
> >> support to feed into discourse instead? Then discourse would be the view 
> >> layer instead of trying to the the truth of the data.
> >>
> >> -David
> > ___
> > 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] Improved value and move semantics

[Dave Abrahams via swift-evolution]

on Wed Aug 03 2016, Matthew Johnson  wrote:

>> On Aug 2, 2016, at 4:54 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Tue Aug 02 2016, Brent Royal-Gordon  wrote:
>> 
>
 On Aug 2, 2016, at 12:06 PM, Dave Abrahams via swift-evolution 
  wrote:
 
 If it says that, it's... not quite right.  There are things we could do
 to make some value copies more optimal.  For example, any value type
 containing multiple class references—or multiple other value types (such
 as arrays or strings or dictionaries) that contain class references—will
 cost more to copy than a single class reference does.  At the cost of
 some allocation and indirection, we could reduce the copying cost of
 such values.  It's an optimization we've considered making, but haven't
 prioritized.  
 
 You can put a CoW wrapper around your value to do it manually.  I hacked
 one up using ManagedBuffer for someone at WWDC but I don't seem to have
 saved the code, sadly.
>>> 
>>> Slightly off-topic, but one day I would like to see `indirect` turned
>>> into a generalized COW feature:
>>> 
>>> * `indirect` can only be applied to a value type (or at least to a
>>> type with `mutating` members, so reference types would have to gain
>>> those).
>>> * The value type is boxed in a reference type.
>>> * Any use of a mutating member (and thus, use of the setter) is
>>> guarded with `isKnownUniquelyReferenced` and a copy.
>>> * `indirect` can be applied to an enum case with a payload (the
>>> payload is boxed), a stored property (the value is boxed), or a type
>>> (the entire type is boxed).
>>> 
>>> Then you can just slap `indirect` on a struct whose copying is too
>>> complicated and let Swift transparently COW it for you. (And it would
>>> also permit recursive structs and other such niceties.)
>> 
>> My vision for this feature is:
>> 
>> a. We indirect automatically based on some heuristic, as an
>>   optimization.
>> 
>> b. We allow you to indirect manually.
>> 
>> c. We provide an attribute that suppresses automatic indirection to
>>   whatever depth possible given resilience boundaries.
>
> This all sounds great.  Does any of this fit into Swift 4 (either
> phase 1 or phase 2)?  It seems like at least the automatic part would
> have ABI impact.

Yes.  In principle, all of it has the potential to fit in Swift 4.  I'm
not sure what will actually happen of course.

-- 
-Dave

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

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Daniel Duan via swift-evolution]

Keep in mind: switching to a different set of tools would create disruptions to 
the core team’s workflow. Context switch is expensive and perhaps hard to 
understand from outside. Quite a few core team members are active participants 
of mailing lists out side of Swift.org (yes, those indeed exist! e.g. llvm). So 
to use a another set of tool, as we say here, is *purely additive* to a lot of 
folks. I can’t speak for the team, but the fact that we are here is a strong 
indication of their preference. Unless you are unsatisfied with the Swift 3 
process/outcome, I’d the mailing list has proven to be working fantastically.
> On Aug 3, 2016, at 1:34 PM, Jacob Bandes-Storch  wrote:
> 
> As I mentioned at the top of this thread, Discourse provides free hosting for 
> community-friendly open-source projects 
> 
>  which I suspect would include Swift. If not, that would indeed throw a 
> wrench in the idea.
> 
> On Wed, Aug 3, 2016 at 1:30 PM, Daniel Duan via swift-evolution 
> > wrote:
> I’d rather the core team work on the language, stdlib and the compiler. 
> Wouldn’t you agree?
> 
> > On Aug 3, 2016, at 12:59 PM, Brandon Knope via swift-evolution 
> > > wrote:
> >
> > I wasn't expecting someone else to do it! This would need to be supported 
> > by the core team 100%
> >
> > Brandon
> >
> >> On Aug 3, 2016, at 3:42 PM, David Owens II  >> > wrote:
> >>
> >>
> >>> On Aug 3, 2016, at 5:21 AM, Brandon Knope via swift-evolution 
> >>> > wrote:
> >>>
> >>> I still think it is worth doing a test to see how everyone likes it:
> >>
> >> Even if it is better, someone if going to have to either maintain the 
> >> server and install of discourse _or_ pay discourse to host it. Until 
> >> someone on the core team agrees to those terms, what’s the point really?
> >>
> >> Has anyone looked into the possibility of extending discourse’ mail 
> >> support to feed into discourse instead? Then discourse would be the view 
> >> layer instead of trying to the the truth of the data.
> >>
> >> -David
> > ___
> > 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] MemoryLayout for a value

[Dave Abrahams via swift-evolution]

Having seen the effects in the standard library and in other
code, I'm concerned that we may have made a mistake in removing
`sizeofValue` et al without providing a replacement.  In the standard
library, we ended up adding an underscored API that allows

  MemoryLayout._ofInstance(someExpression).size

Where someExpression is an autoclosure, and thus not evaluated.  I
wanted to bring up the possibility of introducing a replacement as a
bufix.

I propose that the way to express the above should be:

  MemoryLayout.of(type(of: someExpression)).size

implementable as:

  extension MemoryLayout {
@_transparent
public
static func of(_: T.Type) -> MemoryLayout.Type {
  return MemoryLayout.self
}
  }

I think this API would solve the concerns I had about confusability that
led me to advocate dropping the ability to ask for the size of a value.
The only way to use it is to pass a type and these two expressions have
equivalent meaning:

MemoryLayout
MemoryLayout.of(Int.self)

It also has the benefit of isolating the autoclosure magic to type(of:).

,[ Aside ]
| A slightly cleaner use site is possible with a larger API change:
| 
|   MemoryLayout(type(of: someExpression)).size
| 
| Which would involve changing MemoryLayout from an `enum` to
| a `struct` and adding the following:
| 
|   extension MemoryLayout {
| public init(_: T.Type) {}
| 
| public var size: Int { return MemoryLayout.size }
| public var stride: Int { return MemoryLayout.stride }
| public var alignment: Int { return MemoryLayout.alignment }
|   }
| 
| However I am concerned that dropping ".of" at the use site is worth the
| added API complexity.
`

Thoughts?
-- 
-Dave

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

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Jacob Bandes-Storch via swift-evolution]

As I mentioned at the top of this thread, Discourse provides free hosting
for community-friendly open-source projects

which
I suspect would include Swift. If not, that would indeed throw a wrench in
the idea.

On Wed, Aug 3, 2016 at 1:30 PM, Daniel Duan via swift-evolution <
swift-evolution@swift.org> wrote:

> I’d rather the core team work on the language, stdlib and the compiler.
> Wouldn’t you agree?
>
> > On Aug 3, 2016, at 12:59 PM, Brandon Knope via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I wasn't expecting someone else to do it! This would need to be
> supported by the core team 100%
> >
> > Brandon
> >
> >> On Aug 3, 2016, at 3:42 PM, David Owens II  wrote:
> >>
> >>
> >>> On Aug 3, 2016, at 5:21 AM, Brandon Knope via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> I still think it is worth doing a test to see how everyone likes it:
> >>
> >> Even if it is better, someone if going to have to either maintain the
> server and install of discourse _or_ pay discourse to host it. Until
> someone on the core team agrees to those terms, what’s the point really?
> >>
> >> Has anyone looked into the possibility of extending discourse’ mail
> support to feed into discourse instead? Then discourse would be the view
> layer instead of trying to the the truth of the data.
> >>
> >> -David
> > ___
> > 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] [Swift4] Mailing list vs. Forum

[Daniel Duan via swift-evolution]

I’d rather the core team work on the language, stdlib and the compiler. 
Wouldn’t you agree?

> On Aug 3, 2016, at 12:59 PM, Brandon Knope via swift-evolution 
>  wrote:
> 
> I wasn't expecting someone else to do it! This would need to be supported by 
> the core team 100%
> 
> Brandon 
> 
>> On Aug 3, 2016, at 3:42 PM, David Owens II  wrote:
>> 
>> 
>>> On Aug 3, 2016, at 5:21 AM, Brandon Knope via swift-evolution 
>>>  wrote:
>>> 
>>> I still think it is worth doing a test to see how everyone likes it:
>> 
>> Even if it is better, someone if going to have to either maintain the server 
>> and install of discourse _or_ pay discourse to host it. Until someone on the 
>> core team agrees to those terms, what’s the point really?
>> 
>> Has anyone looked into the possibility of extending discourse’ mail support 
>> to feed into discourse instead? Then discourse would be the view layer 
>> instead of trying to the the truth of the data.
>> 
>> -David
> ___
> 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] [Swift4] Mailing list vs. Forum

[Brandon Knope via swift-evolution]

I wasn't expecting someone else to do it! This would need to be supported by 
the core team 100%

Brandon 

> On Aug 3, 2016, at 3:42 PM, David Owens II  wrote:
> 
> 
>> On Aug 3, 2016, at 5:21 AM, Brandon Knope via swift-evolution 
>>  wrote:
>> 
>> I still think it is worth doing a test to see how everyone likes it:
> 
> Even if it is better, someone if going to have to either maintain the server 
> and install of discourse _or_ pay discourse to host it. Until someone on the 
> core team agrees to those terms, what’s the point really?
> 
> Has anyone looked into the possibility of extending discourse’ mail support 
> to feed into discourse instead? Then discourse would be the view layer 
> instead of trying to the the truth of the data.
> 
> -David
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-dev] [Swift 4] Organizing source stability

[Douglas Gregor via swift-evolution]

> On Aug 3, 2016, at 1:16 AM, Brent Royal-Gordon via swift-dev 
>  wrote:
> 
>> On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch via swift-evolution 
>>  wrote:
>> 
>>  • a top-of-file "shebang"-style comment indicating the version, 
>> something like //#swift(4), mirroring the "#if swift" syntax
> 
> `import Swift 3.1`?
> 
> I think this brings up two interesting questions:
> 
> * Do we want to be able to mix files using different versions of Swift in the 
> same module?

No. It simplifies the problem greatly if the whole module is compiled with a 
single Swift version.

> * Do we want to extend these backwards compatibility features beyond the 
> standard library to other modules?

If we can design generally-useful features for handling language versioning, 
that the standard library can adopt, that would be great.

- Doug

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

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[David Owens II via swift-evolution]

> On Aug 3, 2016, at 5:21 AM, Brandon Knope via swift-evolution 
>  wrote:
> 
> I still think it is worth doing a test to see how everyone likes it:

Even if it is better, someone if going to have to either maintain the server 
and install of discourse _or_ pay discourse to host it. Until someone on the 
core team agrees to those terms, what’s the point really?

Has anyone looked into the possibility of extending discourse’ mail support to 
feed into discourse instead? Then discourse would be the view layer instead of 
trying to the the truth of the data.

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

Re: [swift-evolution] [META] Gmane and Swift Evolution

[Erica Sadun via swift-evolution]

> On Aug 2, 2016, at 9:22 AM, Ben Rimmington  wrote:
> 
> 
>> On 2 Aug 2016, at 16:16, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> Anyone willing to adopt a proposal or a group and get them updated, please 
>> reply in-thread and submit a PR with changes.
> 
> [SE-0076 ... SE-0090] 
> 
> -- Ben
> 

Here's what's left

proposals/0092-typealiases-in-protocols.md:* Status: **Implemented in Swift 
3.0** 
([Rationale](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17317))
proposals/0094-sequence-function.md:Swift-evolution thread: [Discussion thread 
topic for that 
proposal](http://thread.gmane.org/gmane.comp.lang.swift.evolution/15743/focus=17108)
proposals/0094-sequence-function.md:[SE-0045a]: 
http://article.gmane.org/gmane.comp.lang.swift.evolution/16119
proposals/0095-any-as-existential.md:Discussion threads: 
[pre-proposal](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018109.html),
 [review thread 
1](http://thread.gmane.org/gmane.comp.lang.swift.evolution/18349), 
[2](http://thread.gmane.org/gmane.comp.lang.swift.evolution/18350/focus=18447), 
[3](http://thread.gmane.org/gmane.comp.lang.swift.evolution/18351/focus=18440), 
[4](http://thread.gmane.org/gmane.comp.lang.swift.evolution/18518), 
[post-review 
thread](http://thread.gmane.org/gmane.comp.lang.swift.evolution/19463)
proposals/0096-dynamictype.md:[RFC: didset and 
willset](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17534)
proposals/0097-negative-attributes.md:[RFC: didset and 
willset](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17534)
proposals/0098-didset-capitalization.md:[RFC: didset and 
willset](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17534)
proposals/0099-conditionclauses.md:[\[Pitch\] making where and ,
interchangeable in guard 
conditions](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17926)
proposals/0101-standardizing-sizeof-naming.md:* Swift Evolution Pitch: 
[\[Pitch\] Renaming sizeof, sizeofValue, strideof,   
strideofValue](http://thread.gmane.org/gmane.comp.lang.swift.evolution/19459)
proposals/0101-standardizing-sizeof-naming.md:* [Earlier 
Discussions](http://thread.gmane.org/gmane.comp.lang.swift.evolution/15830)
proposals/0101-standardizing-sizeof-naming.md:* [SE-0101 
Review](http://thread.gmane.org/gmane.comp.lang.swift.evolution/21103)
proposals/0103-make-noescape-default.md:* [Make non-escaping closures the 
default](http://thread.gmane.org/gmane.comp.lang.swift.evolution/19756)
proposals/0105-remove-where-from-forin-loops.md:Swift Evolution Discussion: 
[\[Pitch\] Retiring `where` from for-in 
loops](http://thread.gmane.org/gmane.comp.lang.swift.evolution/20142)
proposals/0106-rename-osx-to-macos.md:Swift Evolution Discussion: [\[DRAFT\] 
Aliasing the OS X Platform Configuration   
Test](http://thread.gmane.org/gmane.comp.lang.swift.evolution/20815)
proposals/0108-remove-assoctype-inference.md:swift-evolution thread: 
[pre-proposal](http://thread.gmane.org/gmane.comp.lang.swift.evolution/21714)
proposals/0108-remove-assoctype-inference.md:As Douglas Gregor (original author 
of the relevant type inference code) [puts 
it](http://article.gmane.org/gmane.comp.lang.swift.evolution/22058):
proposals/0108-remove-assoctype-inference.md:To some extent, this is an issue 
inherent to any design which makes no distinctions at the site of 
implementation between members intended to satisfy protocol requirements and 
members that are explicitly not intended to satisfy protocol requirements. 
Rather than adding keywords to create this distinction, Douglas Gregor has 
[proposed and implemented type checker 
heuristics](http://article.gmane.org/gmane.comp.lang.swift.devel/1799) that 
will generate warnings when a programmer implements a member that "looks like" 
it should fulfill a protocol requirement but does not actually do so. This is 
one possible mitigation strategy that should be revisited as a way to decrease 
the possible impact of removing associated type witness inference from the 
compiler.
proposals/0108-remove-assoctype-inference.md:As well, Dave Abrahams expresses a 
[potential 
issue](http://article.gmane.org/gmane.comp.lang.swift.evolution/21892):
proposals/0109-remove-boolean.md:* Status: Accepted 
([Rationale](http://thread.gmane.org/gmane.comp.lang.swift.evolution/23844))
proposals/0109-remove-boolean.md:[Discussion 
thread](http://thread.gmane.org/gmane.comp.lang.swift.evolution/21559)
proposals/0110-distingish-single-tuple-arg.md:Discussion: 
[pre-proposal](http://thread.gmane.org/gmane.comp.lang.swift.evolution/21732)

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

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Kevin Ballard via swift-evolution]

On Wed, Aug 3, 2016, at 11:06 AM, Felipe Cypriano via swift-evolution wrote:
> On Wed, Aug 3, 2016, at 03:01, Brent Royal-Gordon via swift-
> evolution wrote:
 3. Native on every platform.
>>> Browsers too.
>>
>> Safari is native, but Discourse in Safari is not by any means
>> native. Any
>> attempt to define things otherwise would produce a vacuous
>> definition of
>> the term "native".
>
> The same can be said about an email client and what it renders.

No it can't. An email client renders text (possibly with HTML styling
applied, but most mailing list traffic is just text). The issue of it
being native or not pertains to everything *except for* the text. All of
the chrome, all of the controls for manipulating the client, navigating
between messages, writing replies, etc. All of that stuff is native in
an email client, and non-native in forums software like Discourse.

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

[swift-evolution] [swift 4] static libs/modular code, fixed-size arrays, ref/pointer to structs, pointers, numeric types.

[Raphael Sebbe via swift-evolution]

Heard about the Swift 4 thing, so here are a few thoughts about the current
version of Swift (3). We work on a sizeable code base, with a focus on
modular code that is shared across our apps. Sorry if these things have
been discussed already, just joined, and wanted to share a snapshot of our
experience.

1. Swift is very good for lots of stuff. My favorite is code clarity and
conciseness. Math code is great in Swift too (where I typically used
Obj-C++ previously). I can feel the potential of development going faster
and code getting safer at the same time. Love it.

2. Need for static libraries (or equivalent): let me give you an example of
how we organize our code. We have an image processing library, XXX, which
currently has 2 backends : XXX+Metal XXX+OpenGL. Orthogonal to that,
another extension allows JPEG file export using a third-party encoder,
XXX+JPEG. Another feature, for when we need to process video buffer,
XXX+CoreVideo which provides handling of native pixelbuffer. All of these
are curently made as static libraries (5 libs for XXX and extensions) that
can be linked into the app depending whether they are needed or not.
Framework could technically be used too, but that is both inefficient (why
link the code at runtime? Launch delay, etc.) and it does not scale (we'd
need 20 frameworks to build a single app).

Swift, with its extension concept, is very well suited to modular
development like this. We'd like to have a better option than frameworks to
build reusable libraries. It's not an ABI thing, we really don't care about
that, we use libs just to organize code, building them as a part of the
app, and *not* to provide precompiled libraries to some other developers.
Swift package manager does not work well within Xcode either at this time,
and has a number of constraints we don't want (like having a separate git
repo for each static lib -> that's not practical at all if you just have 1
or 2 files in that lib).

I met 4 people at WWDC from both Swift and Xcode teams, but I'm not sure
this topic went through. This is a major concern: organizing reusable code
efficiently is what will bring Swift into larger projects where it could
really shine. We're currently using a hack to enable modular development in
Swift (static libs), and that should be addressed as fast as possible, all
languages have that, we shouldn't wait for Swift 5 or 6 to get it. This is
by far our number one concern with Swift.

3. Fixed-size Arrays are missing. They are useful in some contexts like:
struct Quad { CGPoint corners[4]; }
using a let array makes values immutable, using a var Array makes array
*size* mutable, which is not what is needed here.

4. Reference/pointer to structs: accessing & modifying structs deep into
the model currently requires fully qualified path to the struct instance.
Fully qualifying an inner struct in your data model can be very tedious,
depending on model complexity.

For instance, with scoped access solutions made with Swift 3, you need to
cascade blocks if you need to access multiple inner structs, which doesn't
scale well as it creates code pyramids:

scopedAccess() {
 scopedAccess() {
  // modify varA & varB
 }
}

It's easily done in C/C++ using pointers/references. To make that better,
we'd need some kind of language support IMO.

5. Memory / pointer access, including casting. It's too verbose currently
IMO when compared to C. Should be better supported for a language that is
also targeting low-level (network, disk storage). A syntax that is both
fast (like C) and safe would be great.

6. Explicit casting between numeric types (CGFloat / Double / etc.) are
cumbersome, or Int and float types. Some kind of auto promotion would be
nice.

7. I'm also fan of async/await kind of stuff, asynchronous flows, etc., but
this has already been mentioned -> cool!

Thank you for reading.

Raphael
-- 
Raphael Sebbe, @rsebbe (twitter)
creaceed.com — Apps for Mac • iPhone • iPad
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Felipe Cypriano via swift-evolution]

On Wed, Aug 3, 2016, at 03:01, Brent Royal-Gordon via swift-evolution wrote:
>>> 3. Native on every platform.
>> Browsers too.
>
> Safari is native, but Discourse in Safari is not by any means
> native. Any
> attempt to define things otherwise would produce a vacuous
> definition of
> the term "native".

The same can be said about an email client and what it renders.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Generic subscripts

[Haravikk via swift-evolution]

> * Who is interested in this feature?

Me definitely, everyone probably.

> * Should it be severed from throwing subscripts?

That depends I guess; subscripts are basically functions anyway so it didn't 
make a lot of sense to me that they lacked features that functions have, so if 
implementing both of these features is basically just a case of linking up the 
same behaviour from functions then I say do them simultaneously if possible. I 
don't know much about the actual implementation details though so obviously 
someone else should make a final decision ;)

Basically I'm in favour making subscripts have as much in common with functions 
as possible; in fact they really should just be a property-like shorthand for a 
regular function behind the scenes.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Swift 4.0] Conditional conformances via protocol extensions

[Manav Gabhawala via swift-evolution]

In the generics manifesto
(https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md)
conditional conformances via protocol extensions is under unlikely.

The manifesto notes:

"This is an extremely powerful feature: is allows one to map the
abstractions of one domain into another domain (e.g., every Matrix is
a Graph). However, similar to private conformances, it puts a major
burden on the dynamic-casting runtime to chase down arbitrarily long
and potentially cyclic chains of conformances, which makes efficient
implementation nearly impossible."

Correct me if I’m completely wrong here but I think this is a super
useful feature and is worth talking about.
Firstly why its super useful if not immediately clear is cause you can
do neat things like:

extension Collection : Equatable where Element: Equatable

And you can even make protocols in a module that you did not write
conform to an arbitrary other protocol and give it a default
implementation.


I was wondering why this would put any more of a burden on the runtime
than simple inheritance of protocols. The way this could be
implemented is to augment the ConformanceTable for nominal types by
looking up its protocol extension’s inheritance clauses. I can
definitely see this impacting compile time but I don’t see why runtime
performance will be any different than simple inheritance. Further,
cyclic chains can be detected and broken (compiler error) during the
second pass of semantic analysis.

I had a (perhaps naïve) implementation here:
https://github.com/apple/swift/pull/2233 and I think now would be a
great time to talk about such a feature.

Its possible I completely overlooked something but I would like a more
a detailed explanation about why this isn’t possible.

Regards,
Manav Gabhawala
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Generic subscripts

[Chris Lattner via swift-evolution]

On Aug 3, 2016, at 12:25 AM, Brent Royal-Gordon via swift-evolution 
 wrote:
> I'm looking for consensus on, and a coalition for, including generic 
> subscripts in Phase 1 of the Swift 4 design cycle.

> What I'd like to figure out at this point is:
> 
> * Who is interested in this feature?

This is a very commonly requested feature.  I consider it an obvious omission, 
not something that needs extensive design work.  A proposal would be 
appropriate to capture the effort though.  It should include generic properties 
as well (generic over the result type).

> * Should it be severed from throwing subscripts?

Yes, perfectly reasonable.

> * Does the core team agree that this is in Phase 1's scope?

I’ll defer to the standard library gurus to figure this out.  It doesn’t sound 
like one of the most critical missing features, but I would love to see this 
happen at some point.

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

Re: [swift-evolution] [Idea] Generic subscripts

[Jacob Bandes-Storch via swift-evolution]

+1 from me on this feature as well. It seems like a pretty obvious way in
which subscripts should be like functions, but aren't yet.

Would there be any need for setters and getters to have different generic
parameters? I suppose today there's only one place to specify the type of
the parameters, and the type of the value being retrieved/set, so it's a
moot point.

On Wed, Aug 3, 2016 at 6:33 AM Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Aug 3, 2016, at 2:25 AM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I'm looking for consensus on, and a coalition for, including generic
> subscripts in Phase 1 of the Swift 4 design cycle.
> >
> > The Need
> > -
> >
> > While prototyping my deferred [SE-0132][], I ran into trouble
> introducing `RangeExpression`, an abstraction to make the introduction of
> subrange features easier. Since RangeExpression is a protocol compatible
> with any index type, it has to have an associated type, and thus cannot be
> handled with an existential. I therefore had to add an overloaded subscript
> for each type, which partially defeated the purpose of having the protocol.
> >
> > The lack of generic subscripts also forced a nasty workaround for a
> convenience subscript in [SE-0131][]. That proposal extends `Dictionary
> where Key == AnyHashable` (actually a hidden `_AnyHashableProtocol`, but
> that's a different story) with a convenience subscript which takes any
> `Hashable` type—except that, because generic subscripts are impossible, [it
> instead has to take a hidden `_Hashable` type instead][anyhash-subscript].
> >
> > The generics manifesto suggests a third use case: [a subscript that can
> take any Collection of Index][manifesto].
> >
> > The lack of this feature at the very least impacts binary compatibility
> directly. It also affects source compatibility in that features like
> subranges are designed around its absence, forcing workarounds which affect
> userspace. I see good reasons to do it now and few to delay.
> >
> > Prior Art
> > ---
> >
> > As mentioned, SE-0131 and SE-0132 would have benefited from this feature.
> >
> > After a brief and mostly positive [discussion][], Harlan Haskins and
> Robert Widmann submitted a [pull request][] late in the Swift 3 cycle for
> generic and throwing subscripts. Personally, I think throwing subscripts
> are something we should include, but they're a separate issue and may not
> be appropriate for Phase 1; I would suggest severing the two parts of the
> proposal.
> >
> > Next Steps
> > ---
> >
> > What I'd like to figure out at this point is:
> >
> > * Who is interested in this feature?
>
> I am interested in this feature, both for specific applications as well as
> because it lifts what feels like an arbitrary restriction.
>
> One very common use case is in libraries that handle loosely typed data
> (JSON, Plist, etc).
>
> It’s also worth noting that they will allow us to simulate higher-rank
> functions more directly than we can today (with subscript as function
> application).
>
> >
> > * Should it be severed from throwing subscripts?
>
> Throwing subscripts are important, but don’t necessarily need to be
> introduced at the same time as generic subscripts.  However, the use case
> of libraries that handle loosely typed data will require both.  I believe
> that use case was the motivation for the proposal introduced by Harlan and
> Robert which is why both features were included.
>
> >
> > * Does the core team agree that this is in Phase 1's scope?
> >
> > * Do the people who might be able to implement this have any comments on
> it?
> >
> >
> >
> >   [SE-0132]: <
> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md
> >
> >   [SE-0131]: <
> https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md#detailed-design
> >
> >   [anyhash-subscript]: <
> https://github.com/apple/swift/blob/e051c61c4d7eb33cdbb47b8ac04eae38203a61e6/stdlib/public/core/HashedCollectionsAnyHashableExtensions.swift.gyb#L147
> >
> >   [manifesto]: <
> https://github.com/apple/swift/blob/e3d8448bbdd059a55a6e72c24d07e994afaf5926/docs/GenericsManifesto.md#generic-subscripts
> >
> >   [discussion]: <
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/021450.html
> >
> >   [pull request]:  >
> >
> > --
> > Brent Royal-Gordon
> > Architechies
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Muse M via swift-evolution]

If Swift team have no roadmap on those plans, any swift developers with
strong in each area could kickstart and contributing libraries in Github
repo. We will greatly benefit from those areas and AI.

On Wed, Aug 3, 2016 at 11:10 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Wed, Aug 3, 2016 at 9:48 AM, Nevin Brackett-Rozinsky via
> swift-evolution  wrote:
>
>> A few things immediately spring to mind:
>> • Fixed-size arrays
>> • An optimized Matrix type
>> • Swifty syntax for Fourier transforms
>> • A numerical integrator (or diff-eq solver!)
>> • BigInt capabilities
>>
>> The first of these (fixed-size arrays) will probably require compiler
>> support.
>>
>> The rest can already be done in a library, except I believe they will hit
>> the “generics cannot be specialized across module boundaries” slowdown, and
>> must be explicitly specialized for common numeric types to avoid it. (Has
>> this been fixed yet? Are there plans to?)
>>
>
> The underlying libraries provide optimized versions of matrix functions
> and Fourier transforms only for particular numeric types anyway. It'd be
> Swifty to have Matrix, but doing matrix multiplication with
> that simply isn't going to be performant.
>
>
>>
>> Nevin
>>
>>
>>
>> On Wed, Aug 3, 2016 at 8:41 AM, Björn Forster 
>> wrote:
>>
>>> Hello Swift community,
>>> to make use of Swift more appealing and useful for science, engineering
>>> and finance and everything else involving actually calculating things, I
>>> think it would be a big step forward if Swift would ship with its own
>>> math/numerics library.
>>>
>>> Wouldn't it be great if Swift would offer functionality similar to Numpy
>>> in its native math lib? It think it would be great to have a "standard"
>>> annotation for vector arithmetic that the Swift community has agreed on and
>>> that scientific packages can build on.
>>>
>>> Which functionality should be covered by a Swift's math lib and where
>>> should be drawn the line?
>>>
>>> Any thoughts?
>>>
>>> (If it is not the right time now to talk this topic, as it is not
>>> mentioned in the goals for Swift 4 by Chris, I apologize for bringing this
>>> up now. But I think then this should be discussed later at some point not
>>> in the infinite future)
>>>
>>> Björn
>>>
>>> ___
>>> 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] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Nevin Brackett-Rozinsky via swift-evolution]

A few things immediately spring to mind:
• Fixed-size arrays
• An optimized Matrix type
• Swifty syntax for Fourier transforms
• A numerical integrator (or diff-eq solver!)
• BigInt capabilities

The first of these (fixed-size arrays) will probably require compiler
support.

The rest can already be done in a library, except I believe they will hit
the “generics cannot be specialized across module boundaries” slowdown, and
must be explicitly specialized for common numeric types to avoid it. (Has
this been fixed yet? Are there plans to?)

Nevin



On Wed, Aug 3, 2016 at 8:41 AM, Björn Forster 
wrote:

> Hello Swift community,
> to make use of Swift more appealing and useful for science, engineering
> and finance and everything else involving actually calculating things, I
> think it would be a big step forward if Swift would ship with its own
> math/numerics library.
>
> Wouldn't it be great if Swift would offer functionality similar to Numpy
> in its native math lib? It think it would be great to have a "standard"
> annotation for vector arithmetic that the Swift community has agreed on and
> that scientific packages can build on.
>
> Which functionality should be covered by a Swift's math lib and where
> should be drawn the line?
>
> Any thoughts?
>
> (If it is not the right time now to talk this topic, as it is not
> mentioned in the goals for Swift 4 by Chris, I apologize for bringing this
> up now. But I think then this should be discussed later at some point not
> in the infinite future)
>
> Björn
>
> ___
> 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] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Tino Heth via swift-evolution]

> to make use of Swift more appealing and useful for science, engineering and 
> finance and everything else involving actually calculating things, I think it 
> would be a big step forward if Swift would ship with its own math/numerics 
> library.
There are several topics that imho would benefit from a standard implementation 
(C++ would be so much nicer with a simple "Point" type…) — math is one big 
piece, but there are many more.
None the less, it seems the core team has no time or interest in supporting 
libraries besides the bare stdlib, and the rest of the community is to 
fragmented to tackle this :-(

It's likely that there will be de-facto standards sooner or later, but it 
doesn't look like we'll have something like boost soon.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Improved value and move semantics

[Matthew Johnson via swift-evolution]

> On Aug 2, 2016, at 4:54 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Tue Aug 02 2016, Brent Royal-Gordon  wrote:
> 
>>> On Aug 2, 2016, at 12:06 PM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> If it says that, it's... not quite right.  There are things we could do
>>> to make some value copies more optimal.  For example, any value type
>>> containing multiple class references—or multiple other value types (such
>>> as arrays or strings or dictionaries) that contain class references—will
>>> cost more to copy than a single class reference does.  At the cost of
>>> some allocation and indirection, we could reduce the copying cost of
>>> such values.  It's an optimization we've considered making, but haven't
>>> prioritized.  
>>> 
>>> You can put a CoW wrapper around your value to do it manually.  I hacked
>>> one up using ManagedBuffer for someone at WWDC but I don't seem to have
>>> saved the code, sadly.
>> 
>> Slightly off-topic, but one day I would like to see `indirect` turned
>> into a generalized COW feature:
>> 
>> * `indirect` can only be applied to a value type (or at least to a
>> type with `mutating` members, so reference types would have to gain
>> those).
>> * The value type is boxed in a reference type.
>> * Any use of a mutating member (and thus, use of the setter) is
>> guarded with `isKnownUniquelyReferenced` and a copy.
>> * `indirect` can be applied to an enum case with a payload (the
>> payload is boxed), a stored property (the value is boxed), or a type
>> (the entire type is boxed).
>> 
>> Then you can just slap `indirect` on a struct whose copying is too
>> complicated and let Swift transparently COW it for you. (And it would
>> also permit recursive structs and other such niceties.)
> 
> My vision for this feature is:
> 
> a. We indirect automatically based on some heuristic, as an
>   optimization.
> 
> b. We allow you to indirect manually.
> 
> c. We provide an attribute that suppresses automatic indirection to
>   whatever depth possible given resilience boundaries.

This all sounds great.  Does any of this fit into Swift 4 (either phase 1 or 
phase 2)?  It seems like at least the automatic part would have ABI impact.

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

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

Re: [swift-evolution] [Idea] Generic subscripts

[Matthew Johnson via swift-evolution]

> On Aug 3, 2016, at 4:16 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Aug 3, 2016, at 1:57 AM, Tino Heth <2...@gmx.de> wrote:
>> 
>>> Since RangeExpression is a protocol compatible with any index type, it has 
>>> to have an associated type
>> I haven't read all linked information, but would the situation change with 
>> generic protocols?
>> Thinks like "AnyGenerator" afaics would be superfluous if we had "protocol 
>> Generator", and the same might be true for RangeExpression.
> 
> No, this is not an appropriate use case for generic protocols. (Nor is 
> Generator/IteratorProtocol, for that matter.)
> 
> Generic protocols would be for cases where a single concrete instance can 
> conform to a protocol using several different types. Genuine use cases for 
> that do exist, but they're few and far between.

Yes, this feature is called “multi-parameter type classes” in Haskell.  Those 
interested in proposing it in Swift might be interested in looking at how the 
feature is used in Haskell.

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

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

Re: [swift-evolution] [Idea] Generic subscripts

[Matthew Johnson via swift-evolution]

> On Aug 3, 2016, at 2:25 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> I'm looking for consensus on, and a coalition for, including generic 
> subscripts in Phase 1 of the Swift 4 design cycle.
> 
> The Need
> -
> 
> While prototyping my deferred [SE-0132][], I ran into trouble introducing 
> `RangeExpression`, an abstraction to make the introduction of subrange 
> features easier. Since RangeExpression is a protocol compatible with any 
> index type, it has to have an associated type, and thus cannot be handled 
> with an existential. I therefore had to add an overloaded subscript for each 
> type, which partially defeated the purpose of having the protocol.
> 
> The lack of generic subscripts also forced a nasty workaround for a 
> convenience subscript in [SE-0131][]. That proposal extends `Dictionary where 
> Key == AnyHashable` (actually a hidden `_AnyHashableProtocol`, but that's a 
> different story) with a convenience subscript which takes any `Hashable` 
> type—except that, because generic subscripts are impossible, [it instead has 
> to take a hidden `_Hashable` type instead][anyhash-subscript].
> 
> The generics manifesto suggests a third use case: [a subscript that can take 
> any Collection of Index][manifesto].
> 
> The lack of this feature at the very least impacts binary compatibility 
> directly. It also affects source compatibility in that features like 
> subranges are designed around its absence, forcing workarounds which affect 
> userspace. I see good reasons to do it now and few to delay.
> 
> Prior Art
> ---
> 
> As mentioned, SE-0131 and SE-0132 would have benefited from this feature.
> 
> After a brief and mostly positive [discussion][], Harlan Haskins and Robert 
> Widmann submitted a [pull request][] late in the Swift 3 cycle for generic 
> and throwing subscripts. Personally, I think throwing subscripts are 
> something we should include, but they're a separate issue and may not be 
> appropriate for Phase 1; I would suggest severing the two parts of the 
> proposal.
> 
> Next Steps
> ---
> 
> What I'd like to figure out at this point is:
> 
> * Who is interested in this feature?

I am interested in this feature, both for specific applications as well as 
because it lifts what feels like an arbitrary restriction.

One very common use case is in libraries that handle loosely typed data (JSON, 
Plist, etc).  

It’s also worth noting that they will allow us to simulate higher-rank 
functions more directly than we can today (with subscript as function 
application).

> 
> * Should it be severed from throwing subscripts?

Throwing subscripts are important, but don’t necessarily need to be introduced 
at the same time as generic subscripts.  However, the use case of libraries 
that handle loosely typed data will require both.  I believe that use case was 
the motivation for the proposal introduced by Harlan and Robert which is why 
both features were included.

> 
> * Does the core team agree that this is in Phase 1's scope?
> 
> * Do the people who might be able to implement this have any comments on it?
> 
> 
> 
>   [SE-0132]: 
> 
>   [SE-0131]: 
> 
>   [anyhash-subscript]: 
> 
>   [manifesto]: 
> 
>   [discussion]: 
> 
>   [pull request]: 
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

[swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Björn Forster via swift-evolution]

Hello Swift community,
to make use of Swift more appealing and useful for science, engineering and
finance and everything else involving actually calculating things, I think
it would be a big step forward if Swift would ship with its own
math/numerics library.

Wouldn't it be great if Swift would offer functionality similar to Numpy in
its native math lib? It think it would be great to have a "standard"
annotation for vector arithmetic that the Swift community has agreed on and
that scientific packages can build on.

Which functionality should be covered by a Swift's math lib and where
should be drawn the line?

Any thoughts?

(If it is not the right time now to talk this topic, as it is not mentioned
in the goals for Swift 4 by Chris, I apologize for bringing this up now.
But I think then this should be discussed later at some point not in the
infinite future)

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

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Brandon Knope via swift-evolution]

I still think it is worth doing a test to see how everyone likes it:

Move swift-users (users who should see a quick benefit from because it would be 
more familiar) to discourse and see how that plays out. Let people test out all 
of the features and performance before moving the most popular lists. 

Brandon

Sent from my iPad

> On Aug 3, 2016, at 7:42 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
>>> On 03 Aug 2016, at 12:01, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
 On Aug 2, 2016, at 10:46 PM, Jacob Bandes-Storch  
 wrote:
 
 1. Available on every platform.
>>> Browsers too.
>> 
>> True.
>> 
 2. Performant on every platform. (Discourse, for instance, struggles on 
 Android.)
>>> Browsers are heavily tuned for performance, and Discourse is a relatively 
>>> lightweight site. If you prefer the performance of your email client, 
>>> there's mailing list mode.
>> 
>> Discourse is *very* Javascript-heavy and has long had severe performance 
>> issues in some browsers, particularly Chrome on Android. It appears they've 
>> recently taken some steps to mitigate this issue in their most common view 
>> or two, but it's still not nearly where it ought to be.
>> 
 3. Native on every platform.
>>> Browsers too.
>> 
>> Safari is native, but Discourse in Safari is not by any means native. Any 
>> attempt to define things otherwise would produce a vacuous definition of the 
>> term "native".
>> 
 4. Based on open standards with multiple implementations.
>>> Browsers too.
>> 
>> Again, treating the browser as though it is the important piece here renders 
>> the statements meaningless.
>> 
>>> You may argue that the forum itself is too centralized, but Mailman is 
>>> necessarily centralized too.
>> 
>> But Mailman is merely a conveyance. It can be swapped out for an equivalent 
>> email-based conveyance with relatively little effort or inconvenience to 
>> users. Imagine the amount of effort needed to move from Discourse to (say) 
>> phpBB and you'll see the difference.
>> 
>>> And this isn't always a positive: formatting of styled, quoted, and even 
>>> plain text is quite varied among email clients, so popular threads often 
>>> end up looking like huge messes.
>> 
>> This is true. (There was a minor quoting issue with this reply, probably 
>> because you used HTML email.) However, in my experience it *usually* works 
>> out okay. The bigger issue is not really the software, but the wetware: many 
>> people don't really pay attention to the quoting their mail client does.
> 
> It’s not only quoting. Code formatting is a mess and really hinders 
> readability. I try to do my best to use some formatting when I can, but when 
> I’m on the go, with only my iPhone, using Mail, its a pain to write code in 
> posts and replies.
> 
 5. Does not require you to proactively check swift-evolution.
>>> Email notification settings, or full-on mailing list mode, or RSS, can 
>>> solve this.
>> 
>> I haven't used mailing list mode. How good is the fidelity of the posts? How 
>> about the replies? If features don't come across in one direction or 
>> another, email users will be second-class citizens.
>> 
 6. Supports offline reading and drafting.
>>> Mailing list mode or RSS / reply-by-email.
>> 
>> It seems like an awful lot of your solutions are "use Discourse like a 
>> mailing list". To me, that suggests we ought to just have a mailing list.
> 
> He’s not saying "use Discourse like a mailing list”. He’s saying: if you 
> *really* want to use an email client, the option is there. I would only use 
> Discourse if we were using it.
> 
 7. Supports clients with alternate feature sets.
>>> Discourse has RSS feeds and JSON APIs.
>> 
>> So you can invoke the features Discourse already supports from alternate 
>> clients. If you want to, say, search messages in a way that Discourse's API 
>> doesn't permit, you'll have to download and index all the messages. Which 
>> you would have already done if it were a mailing list.
> 
> This example is a bit extreme. I can already find information more easily 
> with Discourse’s search than my mail client search.
> 
 8. Supports bot clients for both sending (like the CI bot) and receiving 
 (like Gmane).
>>> Discourse has an API which can be used for posting. It also supports 
>>> bot-like plugins which can respond to various events, although I imagine 
>>> that requires self-hosting. External bots interested in receiving would 
>>> probably need to poll RSS, or just make use of mailing list mode as a 
>>> receive hook.
>> 
>> Polling isn't great (and polling RSS could easily miss posts, depending on 
>> how the RSS feeds are designed). 
>> 
 9. Supports user-specific automatic filtering.
>>> Topics and categories in Discourse each support a range of notification 
>>> options from "watching" to "muted". My understanding is that these 

[swift-evolution] [Pre-proposal/Discussion] Padding and Smaller Integer Types?

[Haravikk via swift-evolution]

So we have a pretty good set of integer types right now, but one issue I come 
into is when they don't quite fit within the padding of a type. It's not 
something I've ever really thought about before, since most of my background is 
in OOP with reference types (Java for example) and these don't really encourage 
you to think about it, but with value types I find myself doing so quite a lot.

For example, an Int32? has space for a four-byte integer value, plus one extra 
bit to indicate whether it is a .None or a .Some, this means that it's padded 
to 5-bytes. If I create a struct containing an optional Int32, I have seven 
bits of free space before the type grows in size again (more if I target the 
type's stride width), so I could add up to seven Bool values if I wanted in 
this case.
But what if I want to add another small integer? If I add a UInt8 this will 
cause the type's size to grow (as it'll still have one-bit of extra overhead), 
but I may not require the full range from the UInt8.

The simple solution to this might be introduce an Octet type (Int4/UInt4) but 
that may actually be smaller than I need; what if what I would really like is a 
UInt7 type?


Now I'm not very familiar with how other languages solve problems like this; as 
I say I've mostly worked with reference based OOP languages in the past, and 
only worked fleetingly with C (I can modify code, but haven't written anything 
new in it in a very long time), so I guess I'm mostly just looking to find 
those with more knowledge than me on the subject to see if there are some good 
solutions to this? Swift's rich support for optionals, and enums in general, 
make small overheads like this more common, so a neat way to work with them 
would be nice.

In my mind the most perfect option would be some kind of integer type for which 
I can specify a minimum range for what I need, but which I can have scaled in 
size to fill, but avoid growing, my type's size or stride. For example, if my 
type is intended for storage in arrays exclusively, then I might like to use up 
all of the free space in my type's stride width, only growing if it is 
necessary to achieve the minimum range of values I require. So I might require 
a minimum range of 0-127 (7 bits unsigned) but end up with a wider type that I 
can make use of generically by querying the min/max values, i.e- if the 
remaining space is 7-bits then my integer will fill that perfectly, if the 
remaining space is 13-bits I will end up with a 13-bit integer, if remaining 
space is 3-bits the type might grow by 16-bits, giving me a 19-bit integer.
Is such a thing possible? If so, how is it achieved in other languages?


Sorry about the lack of knowledge in my part on this subject; like I say it's 
nothing I've really thought about before, but now that I'm working with a value 
type that I want to pack as efficiently as possible into an array (while 
remaining useful) it's something that is suddenly of interest to me =D

All ideas and thoughts welcome!
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[David Hart via swift-evolution]

> On 03 Aug 2016, at 12:01, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Aug 2, 2016, at 10:46 PM, Jacob Bandes-Storch  wrote:
>> 
>>> 1. Available on every platform.
>> Browsers too.
> 
> True.
> 
>>> 2. Performant on every platform. (Discourse, for instance, struggles on 
>>> Android.)
>> Browsers are heavily tuned for performance, and Discourse is a relatively 
>> lightweight site. If you prefer the performance of your email client, 
>> there's mailing list mode.
> 
> Discourse is *very* Javascript-heavy and has long had severe performance 
> issues in some browsers, particularly Chrome on Android. It appears they've 
> recently taken some steps to mitigate this issue in their most common view or 
> two, but it's still not nearly where it ought to be.
> 
>>> 3. Native on every platform.
>> Browsers too.
> 
> Safari is native, but Discourse in Safari is not by any means native. Any 
> attempt to define things otherwise would produce a vacuous definition of the 
> term "native".
> 
>>> 4. Based on open standards with multiple implementations.
>> Browsers too.
> 
> Again, treating the browser as though it is the important piece here renders 
> the statements meaningless.
> 
>> You may argue that the forum itself is too centralized, but Mailman is 
>> necessarily centralized too.
> 
> But Mailman is merely a conveyance. It can be swapped out for an equivalent 
> email-based conveyance with relatively little effort or inconvenience to 
> users. Imagine the amount of effort needed to move from Discourse to (say) 
> phpBB and you'll see the difference.
> 
>> And this isn't always a positive: formatting of styled, quoted, and even 
>> plain text is quite varied among email clients, so popular threads often end 
>> up looking like huge messes.
> 
> This is true. (There was a minor quoting issue with this reply, probably 
> because you used HTML email.) However, in my experience it *usually* works 
> out okay. The bigger issue is not really the software, but the wetware: many 
> people don't really pay attention to the quoting their mail client does.

It’s not only quoting. Code formatting is a mess and really hinders 
readability. I try to do my best to use some formatting when I can, but when 
I’m on the go, with only my iPhone, using Mail, its a pain to write code in 
posts and replies.

>>> 5. Does not require you to proactively check swift-evolution.
>> Email notification settings, or full-on mailing list mode, or RSS, can solve 
>> this.
> 
> I haven't used mailing list mode. How good is the fidelity of the posts? How 
> about the replies? If features don't come across in one direction or another, 
> email users will be second-class citizens.
> 
>>> 6. Supports offline reading and drafting.
>> Mailing list mode or RSS / reply-by-email.
> 
> It seems like an awful lot of your solutions are "use Discourse like a 
> mailing list". To me, that suggests we ought to just have a mailing list.

He’s not saying "use Discourse like a mailing list”. He’s saying: if you 
*really* want to use an email client, the option is there. I would only use 
Discourse if we were using it.

>>> 7. Supports clients with alternate feature sets.
>> Discourse has RSS feeds and JSON APIs.
> 
> So you can invoke the features Discourse already supports from alternate 
> clients. If you want to, say, search messages in a way that Discourse's API 
> doesn't permit, you'll have to download and index all the messages. Which you 
> would have already done if it were a mailing list.

This example is a bit extreme. I can already find information more easily with 
Discourse’s search than my mail client search.

>>> 8. Supports bot clients for both sending (like the CI bot) and receiving 
>>> (like Gmane).
>> Discourse has an API which can be used for posting. It also supports 
>> bot-like plugins which can respond to various events, although I imagine 
>> that requires self-hosting. External bots interested in receiving would 
>> probably need to poll RSS, or just make use of mailing list mode as a 
>> receive hook.
> 
> Polling isn't great (and polling RSS could easily miss posts, depending on 
> how the RSS feeds are designed). 
> 
>>> 9. Supports user-specific automatic filtering.
>> Topics and categories in Discourse each support a range of notification 
>> options from "watching" to "muted". My understanding is that these settings 
>> are respected by mailing list mode.
> 
> But there's no means to say "I don't care about messages from the CI bot" or 
> "delete this specific type of message someone keeps spamming us with", is 
> there?
> 
>>> 10. Users can privately annotate messages.
>> Discourse has "bookmarks", basically a way of saving individual 
>> posts/replies for yourself. Users can also send themselves private messages 
>> for note-taking purposes.
> 
> To keep stuff I don't care about out of the way, I use Mail.app's color flags 
> to mark threads—yellow for threads 

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Brent Royal-Gordon via swift-evolution]

> On Aug 2, 2016, at 10:46 PM, Jacob Bandes-Storch  wrote:
> 
>> 1. Available on every platform.
> Browsers too.

True.

>> 2. Performant on every platform. (Discourse, for instance, struggles on 
>> Android.)
> Browsers are heavily tuned for performance, and Discourse is a relatively 
> lightweight site. If you prefer the performance of your email client, there's 
> mailing list mode.

Discourse is *very* Javascript-heavy and has long had severe performance issues 
in some browsers, particularly Chrome on Android. It appears they've recently 
taken some steps to mitigate this issue in their most common view or two, but 
it's still not nearly where it ought to be.

>> 3. Native on every platform.
> Browsers too.

Safari is native, but Discourse in Safari is not by any means native. Any 
attempt to define things otherwise would produce a vacuous definition of the 
term "native".

>> 4. Based on open standards with multiple implementations.
> Browsers too.

Again, treating the browser as though it is the important piece here renders 
the statements meaningless.

> You may argue that the forum itself is too centralized, but Mailman is 
> necessarily centralized too.

But Mailman is merely a conveyance. It can be swapped out for an equivalent 
email-based conveyance with relatively little effort or inconvenience to users. 
Imagine the amount of effort needed to move from Discourse to (say) phpBB and 
you'll see the difference.

> And this isn't always a positive: formatting of styled, quoted, and even 
> plain text is quite varied among email clients, so popular threads often end 
> up looking like huge messes.

This is true. (There was a minor quoting issue with this reply, probably 
because you used HTML email.) However, in my experience it *usually* works out 
okay. The bigger issue is not really the software, but the wetware: many people 
don't really pay attention to the quoting their mail client does.

>> 5. Does not require you to proactively check swift-evolution.
> Email notification settings, or full-on mailing list mode, or RSS, can solve 
> this.

I haven't used mailing list mode. How good is the fidelity of the posts? How 
about the replies? If features don't come across in one direction or another, 
email users will be second-class citizens.

>> 6. Supports offline reading and drafting.
> Mailing list mode or RSS / reply-by-email.

It seems like an awful lot of your solutions are "use Discourse like a mailing 
list". To me, that suggests we ought to just have a mailing list.

>> 7. Supports clients with alternate feature sets.
> Discourse has RSS feeds and JSON APIs.

So you can invoke the features Discourse already supports from alternate 
clients. If you want to, say, search messages in a way that Discourse's API 
doesn't permit, you'll have to download and index all the messages. Which you 
would have already done if it were a mailing list.

>> 8. Supports bot clients for both sending (like the CI bot) and receiving 
>> (like Gmane).
> Discourse has an API which can be used for posting. It also supports bot-like 
> plugins which can respond to various events, although I imagine that requires 
> self-hosting. External bots interested in receiving would probably need to 
> poll RSS, or just make use of mailing list mode as a receive hook.

Polling isn't great (and polling RSS could easily miss posts, depending on how 
the RSS feeds are designed). 

>> 9. Supports user-specific automatic filtering.
> Topics and categories in Discourse each support a range of notification 
> options from "watching" to "muted". My understanding is that these settings 
> are respected by mailing list mode.

But there's no means to say "I don't care about messages from the CI bot" or 
"delete this specific type of message someone keeps spamming us with", is there?

>> 10. Users can privately annotate messages.
> Discourse has "bookmarks", basically a way of saving individual posts/replies 
> for yourself. Users can also send themselves private messages for note-taking 
> purposes.

To keep stuff I don't care about out of the way, I use Mail.app's color flags 
to mark threads—yellow for threads I'm following, gray for threads I'm 
ignoring, red for threads on my own proposals, etc.—and then sort the folder by 
flag color. Does Discourse offer anything like that? It seems like it only 
offers a binary "bookmark" option.

>> 11. Drafts and private messages are not visible to any central administrator.
> I'm not sure whether Discourse drafts are saved on the server. Moderators are 
> restricted from viewing private messages.

Private messages are in the database, aren't they? There's no end-to-end 
encryption, is there?

> Of course, you can always contact someone via other means.

By *what* means? Discourse doesn't tell you a person's email address or any of 
their other contact info.

>> 12. History is stored in a distributed fashion; there is no single point of 
>> failure that could wipe out 

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[David Hart via swift-evolution]

I did not have the time to counter all those points but I was going to and 
point that Discourse has a solution for nearly all of those. I would REALLY 
prefer having the mailing-list part of the discussion on Discourse.

> On 03 Aug 2016, at 07:46, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> I hope my replies aren't too curt — I don't want to pick a fight (any more 
> than I did by starting this topic), but to explore how Discourse can serve 
> these use cases. Feel free to re-rebut.
> 
> On Mon, Aug 1, 2016 at 3:03 PM, Brent Royal-Gordon  > wrote:
> 
> I don't think enough has been said in favor of mailing lists. Some advantages 
> for them:
> 
> 1. Available on every platform.
> Browsers too.
>  
> 
> 2. Performant on every platform. (Discourse, for instance, struggles on 
> Android.)
> Browsers are heavily tuned for performance, and Discourse is a relatively 
> lightweight site. If you prefer the performance of your email client, there's 
> mailing list mode.
> 
> 
> 3. Native on every platform.
> Browsers too.
>  
> 
> 4. Based on open standards with multiple implementations.
> Browsers too. You may argue that the forum itself is too centralized, but 
> Mailman is necessarily centralized too.
> 
> And this isn't always a positive: formatting of styled, quoted, and even 
> plain text is quite varied among email clients, so popular threads often end 
> up looking like huge messes.
>  
> 
> 5. Does not require you to proactively check swift-evolution.
> Email notification settings, or full-on mailing list mode, or RSS, can solve 
> this.
> 
> 
> 6. Supports offline reading and drafting.
> Mailing list mode or RSS / reply-by-email.
> 
> 
> 7. Supports clients with alternate feature sets.
> Discourse has RSS feeds and JSON APIs.
>  
> 
> 8. Supports bot clients for both sending (like the CI bot) and receiving 
> (like Gmane).
> Discourse has an API 
>  which can be 
> used for posting. It also supports bot-like plugins 
>  which can 
> respond to various events, although I imagine that requires self-hosting. 
> External bots interested in receiving would probably need to poll RSS, or 
> just make use of mailing list mode as a receive hook.
> 
> 
> 9. Supports user-specific automatic filtering.
> Topics and categories in Discourse each support a range of notification 
> options from "watching" to "muted". My understanding is that these settings 
> are respected by mailing list mode.
>  
> 
> 10. Users can privately annotate messages.
> Discourse has "bookmarks", basically a way of saving individual posts/replies 
> for yourself. Users can also send themselves private messages 
> 
>  for note-taking purposes.
>  
> 
> 11. Drafts and private messages are not visible to any central administrator.
> I'm not sure whether Discourse drafts are saved on the server. Moderators are 
> restricted from viewing private messages 
> . 
> Of course, you can always contact someone via other means.
> 
> 
> 12. History is stored in a distributed fashion; there is no single point of 
> failure that could wipe out swift-evolution's history.
> This is a fair point. But: 
> - The Git repository of proposals is distributed.
> - Discourse is as easily backed up as any other computer system: 
> https://meta.discourse.org/t/configure-automatic-backups-for-discourse/14855 
> 
> - Users who would like a low-fidelity local copy for themselves can enable 
> mailing list mode.
> - Anyone is free to access/archive publicly accessible content using the APIs.
>  
> 
> 13. Usually the medium of choice for large-scale, long-running open source 
> projects.
> 
> Is that just because people already know how to use email? Is it because the 
> projects are so long-running that email was the best/only choice when they 
> started? I'm not sure anyone has done real academic research on the use of 
> mailing lists in open source projects. If someone can find any, I'd be 
> interested to read it.
>  
> 
> I could probably go on, but I'll stop here for now.
> 
> I would love to have a great web archive for swift-evolution—something with a 
> really solid search function, good threading, and most of the other niceties 
> of forums. It'd even be nice to have an upvote feature. But these are all 
> things that you could do without taking swift-evolution off of email.
> 
> This seems like status quo bias to me. It's just as valid to *start* with a 
> great forum system, and build any desirable additional features on top, as it 
> is to start with a mailing list and build additional features on top. 
> 

Re: [swift-evolution] [Idea] Generic subscripts

[Brent Royal-Gordon via swift-evolution]

> On Aug 3, 2016, at 1:57 AM, Tino Heth <2...@gmx.de> wrote:
> 
>> Since RangeExpression is a protocol compatible with any index type, it has 
>> to have an associated type
> I haven't read all linked information, but would the situation change with 
> generic protocols?
> Thinks like "AnyGenerator" afaics would be superfluous if we had "protocol 
> Generator", and the same might be true for RangeExpression.

No, this is not an appropriate use case for generic protocols. (Nor is 
Generator/IteratorProtocol, for that matter.)

Generic protocols would be for cases where a single concrete instance can 
conform to a protocol using several different types. Genuine use cases for that 
do exist, but they're few and far between.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Manifesto] Completing Generics

[Brent Royal-Gordon via swift-evolution]

> On Aug 2, 2016, at 7:58 AM, Patrick Lind via swift-evolution 
>  wrote:
> 
> http://stackoverflow.com/questions/38619660/is-it-possible-to-pass-generic-protocols-into-a-constructor-for-proper-dependenc

I *think* that the specific feature you're looking for here is usually called 
"enhanced existentials". This would have a different syntax—something like 
`RepositoryProtocol where Object == Zombie`—but would do basically the same 
thing.

The way to work around this in Swift 2 or 3 is to manually write a type-erasing 
wrapper:

// Effectively a constructor of AnyRepository.
public func anyRepository(_ repository: 
Repository) -> AnyRepository {
// Don't double-wrap
if let repo = repository as? AnyRepository {
return repo
}
return ConcreteAnyRepository(repository: repository)
}

// This is the public face of the wrapper. It's actually abstract. 
Since it doesn't have the 
// RepositoryProtocol as a parameter, it "erases" the repository's type.
public class AnyRepository: RepositoryProtocol {
private init() {}

public var items: Array {
get { fatalError("abstract") }
set { fatalError("abstract") }
}

public func insert(_ object: Object) {
fatalError("abstract")
}

public func deleteAll() {
fatalError("abstract")
}
}

// All instances of AnyRepository will actually belong to this concrete 
subclass, which 
// *does* have the specific RepositoryProtocol as a parameter.
private class ConcreteAnyRepository: 
AnyRepository {
private let repository: Repository

override var items: Array {
get { return repository.items }
set { repository.items = newValue }
}

override func insert(_ object: Object) {
repository.insert(object)
}

override func deleteAll() {
repository.deleteAll()
}
}

And then your ZombieServiceProtocol can look like:

protocol ZombieServiceProtocol {
func fetchZombies()

var zombieRepository: AnyRepository { get set }
}

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Idea] Generic subscripts

[Tino Heth via swift-evolution]

> Since RangeExpression is a protocol compatible with any index type, it has to 
> have an associated type
I haven't read all linked information, but would the situation change with 
generic protocols?
Thinks like "AnyGenerator" afaics would be superfluous if we had "protocol 
Generator", and the same might be true for RangeExpression.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift 4] Organizing source stability

[Brent Royal-Gordon via swift-evolution]

> On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
>   • a top-of-file "shebang"-style comment indicating the version, 
> something like //#swift(4), mirroring the "#if swift" syntax

`import Swift 3.1`?

I think this brings up two interesting questions:

* Do we want to be able to mix files using different versions of Swift in the 
same module?
* Do we want to extend these backwards compatibility features beyond the 
standard library to other modules?

If the answer to both is "yes", then the compiler can just treat the version of 
the `Swift` module specially, using it to adjust the language syntax in 
addition to the standard library interface. The command-line switch can be one 
that provides a default version for imports with unspecified versions, like:

--version Swift=3.1 --version SomeJSON=1.2

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Adrian Zubarev via swift-evolution]

We need an official poll with all the mentioned options. I believe that would 
make things here a little bit faster.

+1 for something like discourse.



-- 
Adrian Zubarev
Sent with Airmail

Am 3. August 2016 um 09:48:03, Ben Rimmington via swift-evolution 
(swift-evolution@swift.org) schrieb:


> On 1 Aug 2016, at 23:03, Brent Royal-Gordon wrote:
>  
> I would love to have a great web archive for swift-evolution—something with a 
> really solid search function, good threading, and most of the other niceties 
> of forums. It'd even be nice to have an upvote feature. But these are all 
> things that you could do without taking swift-evolution off of email.

Mailman 3 with the HyperKitty archiver has those features. For example:



Swift-evolution is currently using Mailman 2.1.12 with Pipermail.

See also:

*  (March 2015: Mailman 3 review)
*  (April 2014: HyperKitty preview)

-- Ben

___
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] [Swift4] Mailing list vs. Forum

[Ben Rimmington via swift-evolution]

> On 1 Aug 2016, at 23:03, Brent Royal-Gordon wrote:
> 
> I would love to have a great web archive for swift-evolution—something with a 
> really solid search function, good threading, and most of the other niceties 
> of forums. It'd even be nice to have an upvote feature. But these are all 
> things that you could do without taking swift-evolution off of email.

Mailman 3 with the HyperKitty archiver has those features. For example:



Swift-evolution is currently using Mailman 2.1.12 with Pipermail.

See also:

*  (March 2015: Mailman 3 review)
*  (April 2014: HyperKitty preview)

-- Ben

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

[swift-evolution] [Idea] Generic subscripts

[Brent Royal-Gordon via swift-evolution]

I'm looking for consensus on, and a coalition for, including generic subscripts 
in Phase 1 of the Swift 4 design cycle.

The Need
-

While prototyping my deferred [SE-0132][], I ran into trouble introducing 
`RangeExpression`, an abstraction to make the introduction of subrange features 
easier. Since RangeExpression is a protocol compatible with any index type, it 
has to have an associated type, and thus cannot be handled with an existential. 
I therefore had to add an overloaded subscript for each type, which partially 
defeated the purpose of having the protocol.

The lack of generic subscripts also forced a nasty workaround for a convenience 
subscript in [SE-0131][]. That proposal extends `Dictionary where Key == 
AnyHashable` (actually a hidden `_AnyHashableProtocol`, but that's a different 
story) with a convenience subscript which takes any `Hashable` type—except 
that, because generic subscripts are impossible, [it instead has to take a 
hidden `_Hashable` type instead][anyhash-subscript].

The generics manifesto suggests a third use case: [a subscript that can take 
any Collection of Index][manifesto].

The lack of this feature at the very least impacts binary compatibility 
directly. It also affects source compatibility in that features like subranges 
are designed around its absence, forcing workarounds which affect userspace. I 
see good reasons to do it now and few to delay.

Prior Art
---

As mentioned, SE-0131 and SE-0132 would have benefited from this feature.

After a brief and mostly positive [discussion][], Harlan Haskins and Robert 
Widmann submitted a [pull request][] late in the Swift 3 cycle for generic and 
throwing subscripts. Personally, I think throwing subscripts are something we 
should include, but they're a separate issue and may not be appropriate for 
Phase 1; I would suggest severing the two parts of the proposal.

Next Steps
---

What I'd like to figure out at this point is:

* Who is interested in this feature?

* Should it be severed from throwing subscripts?

* Does the core team agree that this is in Phase 1's scope?

* Do the people who might be able to implement this have any comments on it?



[SE-0132]: 

[SE-0131]: 

[anyhash-subscript]: 

[manifesto]: 

[discussion]: 

[pull request]: 

-- 
Brent Royal-Gordon
Architechies

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