Re: [swift-evolution] [META] Re: Mailman?

munity owners abdicating their own responsibility for > moderating their communities. > > -Joe > >> On Mar 9, 2016, at 2:34 AM, Adrian Kashivskyy via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I'm a very b

Re: [swift-evolution] Removing explicit use of `let` from Function Parameters

+1, this should be consistent. P.S. Finally somebody wrote an email using non-black Comic Sans.  Pozdrawiam – Regards, Adrian Kashivskyy > Wiadomość napisana przez Nicholas Maccharoli via swift-evolution > w dniu 17.03.2016, o godz. 09:27: > > ​As a follow-up to

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

+1 for Self and the proposal. Pozdrawiam – Regards, Adrian Kashivskyy > Wiadomość napisana przez Bernd Ohr (jazzbox) via swift-evolution > w dniu 06.04.2016, o godz. 09:11: > > I am using a typealias for this: > > struct MyStruct { >private typealias _Self =

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

@Patrick, > I rarely use the result value of removeLast() and I don't see how requiring > it here adds any safety. It is obvious this call has side-effects and doesn't > just return the last element. Actually, removeLast() and other pop()-like functions are examples of functions that will

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

I believe the scoped @discardableResult(warn|critical) attribute is a nice idea for future directions, but I'm not sure it's in scope of this proposal, which, as a first small step, aims to basically invert the @warn_unused_result standard. cc Erica Pozdrawiam – Regards, Adrian Kashivskyy >

Re: [swift-evolution] private & fileprivate

I’m +1 on the following: current new private private fileprivate private(file) internal private(module) public public open open The only thing that keeps bothering me is private(set) and how it will harmonize with this proposed scheme. Regards, Adrian Kashivskyy > Wiadomość napisana przez

Re: [swift-evolution] [Review] SE-0143: Conditional Conformances

> What is your evaluation of the proposal? Very strong +1. > Is the problem being addressed significant enough to warrant a change to > Swift? Yes. Lack of conditional conformances is a very painful limitation of the generics system and adding it would simplify many APIs throughout the

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

I’m also -1 on disallowing emojis as identifiers. As it was stated may times before, emojis are an important part of modern communication, especially between young people and kids. I understand the complexity of keeping them around, especially if they are not well-defined by Unicode and if

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning (Revised)

> What is your evaluation of the proposal? +1. I think > Is the problem being addressed significant enough to warrant a change to > Swift? Yes, version pinning is a must-have feature for collaboration in larger scale. > Does this proposal fit well with the feel and direction of Swift? Yes,

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

I vote to incorporate it somehow into the “Universal Self ” proposal. – Adrian___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

I’m -1 as it’s currently written, for the following reasons: 1. Differences are introduced to pattern matching in different parts of the language (`switch` vs `if`/`guard` vs `for`). 2. Exclusion of `for` in the proposal is either deliberate (which relates to point 1.) or done as a result of a

Re: [swift-evolution] Official Swift Slack team?

In my opinion, real-time chat does not have any advantages for swift-evolution discussions. I am a strong supporter of moving to Discourse, though. – Adrian > Wiadomość napisana przez Goffredo Marocchi via

[swift-evolution] [Review] SE-0159: Fix Private Access Levels

Hi, > What is your evaluation of the proposal? +1, I’ve experienced the described problem in my projects. > Is the problem being addressed significant enough to warrant a change to > Swift? Yes. > Does this proposal fit well with the feel and direction of Swift? Yes. > If you have used

Re: [swift-evolution] Reproducible builds (same code -> always same binary)

Hi, > Have you considered adding reproducible builds to Swift? If you compile the > same code under the same conditions, you always get the same binary. I don’t honestly know if „reproducible builds” are part of ABI stability, but if you are interested in that, you can find more information in

Re: [swift-evolution] [draft] Introduce Sequence.filteredMap(_:)

+1 from me as well. —— Adrian Kashivskyy On 24 Oct 2017, 00:24 +0200, BJ Homer via swift-evolution , wrote: > I strongly agree! In fact, I just started writing up a similar proposal the > other day, but hadn’t had time to finish it yet. > > The current name for this

Re: [swift-evolution] [SPM] Roadmap?

> I would like Xcode integration  The last thing I want from a platform-agnostic open-source package manager is built-in integration with a single-platform commercial closed-source IDE.  I think this should be done independently by DT team, without any special  favouritism by SPM. —— Adrian