Re: [swift-evolution] Constrained Protocol Aliases

Hart is also interested in this one. (cc) > > > Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution > (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb: > >> Hello, Swift community! >> >> I'd like to start a dis

[swift-evolution] Constrained Protocol Aliases

Hello, Swift community! I'd like to start a discussion about a possibility of constrained protocol aliases. The declaration would look like this: typealias BinaryProtocol = RandomAccessCollection & MutablCollection & RangeReplaceableCollection where Binary.Index == Int, Binary.Element == Bool

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

I disagree about the back-conversion being different. I would've just as easily made a property in CasualAnswer that returns a Bool. The fact that its implemented as an extension of Bool is purely cosmetic and avoids namespace clutter. Also, it doesn't make sense to add semantics to the

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

> On Aug 2, 2017, at 8:23 PM, Taylor Swift wrote: > > > > On Wed, Aug 2, 2017 at 12:45 PM, Gor Gyolchanyan > > wrote: > >> On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution >>

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

> On Aug 2, 2017, at 4:35 AM, Xiaodi Wu via swift-evolution > wrote: > > On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift > wrote: > > > On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

> On Aug 2, 2017, at 7:31 PM, Tino Heth <2...@gmx.de> wrote: > > >> Consider these two alternative ways of writing the same code: >> https://gist.github.com/technogen-gg/17b6d5e13c13080850dceda28cfe1caa >> > Great example

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

Consider these two alternative ways of writing the same code: https://gist.github.com/technogen-gg/17b6d5e13c13080850dceda28cfe1caa > On Aug 2, 2017, at 6:57 PM, Taylor Swift wrote: > > I don’t

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

tol body, even without the constraints. Compiler would never know, > dropFirst returns an AnySequence or associatetype Subsequence. > This is a bit different. The implementation is provided in a constrained extension. Depending on the exact type that conforms to Sequence, it may or may not be implem

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

> On Aug 2, 2017, at 6:18 PM, Tino Heth <2...@gmx.de> wrote: > > Hi Gor, > > [I'll continue to answer below, but that wont help you with your proposal…] > > The question is wether this > protocol Equatable { > > static func == (_ some: Self, _ other: Self) -> Bool > > default

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

> On Aug 2, 2017, at 6:15 PM, Taylor Swift wrote: > > I agree with this, extensions on types defined in the same file are generally > silly, and default implementations belong in the protocol body. I don’t agree > with certain style guides prescription of same-file

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

oposed limitations to question. By the way, thank you for doing that  > > On Wed, Aug 2, 2017 at 03:54 Gor Gyolchanyan via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > Good day, swift community! > This time, I'd like to

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

> On Aug 2, 2017, at 3:33 PM, Tino Heth <2...@gmx.de> wrote: > > >> The same-file mentality comes from Swift 3, which introduced fileprivate >> (which, since Swift 4, got merged into private within a single file scope). >> With that feature, implementors don't have to choose between access

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

> On Aug 2, 2017, at 1:26 PM, Tino Heth <2...@gmx.de> wrote: > > >> That would work as well, but it has the downside of forcing a potentially >> huge number of methods to be implemented in a single place, reducing the >> readability as opposed to packing them into semantically related groups

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

That would work as well, but it has the downside of forcing a potentially huge number of methods to be implemented in a single place, reducing the readability as opposed to packing them into semantically related groups in the form of extensions. Also, please include the original message for

[swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

Good day, swift community! This time, I'd like to bring your attention to an everyday problem which, I'm sure, you've all dealt with at some point. Motivation Many protocols have a lot of default-implemented requirements so that they can be customized, which would otherwise be impossible to

Re: [swift-evolution] [discussion] compile-time execution and metaprogramming (was: "constexpr" for Swift 5)

I had in mind. I'm curious about how it turned out for them. > I'm no expert, so I'm not sure if there's a reason something like this > wouldn't work in the world of Swift, but it seems extremely elegant and > flexible. > > Jarod > > On Jul 31, 2017, 23:58 -0700, Gor Gyo

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

> On Aug 1, 2017, at 4:53 PM, Daryle Walker wrote: > >> On Jul 31, 2017, at 4:37 PM, Gor Gyolchanyan > > wrote: >> >>> >>> On Jul 31, 2017, at 11:23 PM, John McCall >>

[swift-evolution] [discussion] compile-time execution and metaprogramming (was: "constexpr" for Swift 5)

As with many other threads, the "constexpr" one changed into a fixed-size array thread , so instead of fighting it, let's branch off into another topic that also almost took over. The bottom line of this discussion is to weight pros and cons of a compile-time execution feature and a

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

2017, at 2:09 PM, Gor Gyolchanyan via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> So I was thinking the other day (and by "the other day" I mean "It just >> occurred to me") that Swift'

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

> On Jul 31, 2017, at 11:52 PM, John McCall wrote: > >> On Jul 31, 2017, at 4:37 PM, Gor Gyolchanyan > > wrote: >>> On Jul 31, 2017, at 11:23 PM, John McCall >>

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

> On Jul 31, 2017, at 11:23 PM, John McCall wrote: > >> >> On Jul 31, 2017, at 4:00 PM, Gor Gyolchanyan > > wrote: >> >> >>> On Jul 31, 2017, at 10:09 PM, John McCall >>

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

> On Jul 31, 2017, at 10:09 PM, John McCall wrote: > >> On Jul 31, 2017, at 3:15 AM, Gor Gyolchanyan >> wrote: >>> On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution >>> wrote: >>> On Jul 30, 2017,

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

> On Jul 31, 2017, at 12:16 PM, Tino Heth <2...@gmx.de> wrote: > > >> OTOH, if the compiler can prove that a local array is never resized, why >> *shouldn't* it get all the benefits of a fixed-sized array without having to >> use a special syntax? Put another way, why shouldn't fixed-size be

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

<xiaodi...@gmail.com >> <mailto:xiaodi...@gmail.com>> wrote: >> >> >> On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> > On Jul 31, 2017, at 7:10

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

> On Jul 31, 2017, at 10:40 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > > On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > On Jul 31, 2017, at 7:10 AM, John

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

> On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution > wrote: > >> On Jul 30, 2017, at 11:43 PM, Daryle Walker wrote: >> The parameters for a fixed-size array type determine the type's size/stride, >> so how could the bounds not be needed

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

make this exceedingly easy, because LLVM libraries natively support metadata on pretty much everything, so it would be a simple matter of not forgetting to expose those to Swift as well. > - Chris K > >> On Jul 30, 2017, at 12:03 PM, Gor Gyolchanyan via swift-evolution >> <s

Re: [swift-evolution] [Pitch] Throwing unwrap operators

on-20160404/014272.html> > and https://gist.github.com/erica/5a26d523f3d6ffb74e34d179740596f7 > <https://gist.github.com/erica/5a26d523f3d6ffb74e34d179740596f7> > > -- E > >> On Jul 30, 2017, at 12:30 PM, Gor Gyolchanyan via swift-evolution >> <swift-e

Re: [swift-evolution] [Pitch] Throwing unwrap operators

I like the general direction where this is going, but I haven’t settled on an opinion regarding its appearance yet. I’ve argued before that the gap between optionals and errors should be closed by making it easy to swift from optionals to non-optionals with throwing. The “unwrap-or-die” idea

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

rs and eventually tool support to > selectively toggle expansion, as we can today with code blocks, for example, > in many tools. > > I don’t mean to derail this discussion, but it seems that an annotation or > macro system would be appropriate for this kind of feature. > > - Ch

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

Tino Heth: If you read my reply to Daniel Vollmer, you’ll find that we’re thinking about the exact same thing. Your code snippers show my vision of compiletime beautifully . Now what I really want at this point is to here the opinions of the core team on this topic. Swift Core Team: Have you

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

> On Jul 30, 2017, at 1:03 PM, Daniel Vollmer via swift-evolution > <swift-evolution@swift.org> wrote: > > Hello, > >> On 30. Jul 2017, at 08:52, Gor Gyolchanyan via swift-evolution >> <swift-evolution@swift.org> wrote: > > [snip] > >>

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

I’ve thought about this a lot lately. I think, given llvm’s built-in MCJIT engine and interpreter, it would be relatively easy to skip the under-developed constexpr that C++ settled on and go straight for a more elaborate compile-time facilities, which would also provide extremely powerful meta

Re: [swift-evolution] [Pitch] Update to Alternative Types (i.e. strong typedef) Proposal

I feel like I should mention that Clang has __attribute__((__swift_newtype__)) type attribute that replaces the imported type from typealias to a new RawRepresentable struct. Clang has a variety of poorly documented swift compatibility extensions like this (a lot of which I managed to discover,

Re: [swift-evolution] [pitch] CopyInitializable for value-type semantics

I like the idea of Clonable, because it involves the least amount of boilerplate and I do certainly agree that not having to care about whether or not the object is a value type or a reference type is good for robust generic programming. However, there are two problems that I see with it: * The

Re: [swift-evolution] Idea: Properties in Failable Initializers less verbose

This was one of the issues I tried to address in my proposal about factory initializers (based on all previous discussions on that topic). I’d love to see this happen, but much like the reason why I didn’t push the factory initializers proposal to review, I think now’s not the time for this. The

Re: [swift-evolution] [idea] errors in properties

it! I’m even OK with wrapping stored properties into computed ones because of willSet and didSet not being able to throw (for the time being anyway). Brent, hello! Can you tell me why this proposal of yours is not pushed to review? >> On 25 Jul 2017, at 21:58, Gor Gyolchanyan via swif

Re: [swift-evolution] [idea] errors in properties

ch “swift throwing properties site:lists.swift.org > <http://lists.swift.org/>”. > > The “tldr” seems to be that it’s not supported because no one has written > code to support it yet. > On Tue, Jul 25, 2017 at 15:29 Gor Gyolchanyan via swift-evolution > <swift-evolutio

[swift-evolution] [idea] errors in properties

I’ll just cut to the chase: Why is throwing from get, set, willSet and didSet disallowed? var login: String { willSet throws { guard newValue.count > 5 else { throw LoginError.loginTooSmall } } } try login = “JebediahKerman”

Re: [swift-evolution] [Pitch] Array full proposal

Yes, by nominal tuples I did mean a struct definition somewhere in swift’s standard library. Seems like there are some quirks to tuples in Swift that I’m not aware of. I always assumed that they are packed ordinary structures. Since structure member offset is a compile-time constant, using

Re: [swift-evolution] [Pitch] Array full proposal

I agree, given the current state of Swift, fixed-sized arrays are way too magical. I’d suggest postponing the idea of fixed-sized arrays (even though I myself have ached for them for a long time now) until its prerequisites are met. There are three language features that have been discusses

Re: [swift-evolution] Pitch: Improved Swift pointers

In my understanding, the address manipulation abstractions are as follows: An address is an integer denoting an index into the current address space (which, in case of a user-space process, is a virtual address space, uniquely allocated by the operating system for that process). The minimal

Re: [swift-evolution] [pitch] CopyInitializable for value-type semantics

swifty types. > On Jul 12, 2017, at 6:58 PM, Philippe Hausler <phaus...@apple.com> wrote: > > > >> On Jul 12, 2017, at 3:23 AM, Gor Gyolchanyan via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >

[swift-evolution] [pitch] CopyInitializable for value-type semantics

Hello, swift community! Recently I’ve come across a dilemma regarding value-type semantics when dealing with generic types. Consider a protocol that has a mutating in-place function and a non-mutating returning variant of that function: protocol Transmogrifier { mutating func

Re: [swift-evolution] [Pitch] Extending [at]autoclosure

I have thought of this before, but I always got stuck on the problem of nested closures. Imagine you’re calling a function that takes an auto closure inside another closure. What exactly will `$0` refer to? > On Jun 24, 2017, at 7:10 PM, Adrian Zubarev via swift-evolution >

Re: [swift-evolution] [Idea] Trailing Multi-Line String Literal

>> wrote: > >> > >> Personally, I have never felt that need. > >> > >> Trailing closures fill of need of making Swift a good candidate for > >> building DSLs, where they make the function calls look more like > >> first-class operations. But

Re: [swift-evolution] [Idea] Trailing Multi-Line String Literal

make the function calls look more like first-class > operations. But I don’t think that trailing strings would be as useful. > > David. > >> On 15 Jun 2017, at 11:54, Gor Gyolchanyan via swift-evolution >> <swift-evolution@swift.org> wrote: >> >

[swift-evolution] [Idea] Trailing Multi-Line String Literal

Good day, swift evolution community! I'll just get right to it... Did anyone else beside me wished this was a thing? func parse(allowSomeBehavior: Bool = true, source: String) { // ... } parse(allowSomeBehavior: false) """ This is a source string that contains a number

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

evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>> On 11 Jun 2017, at 22:13, Gor Gyolchanyan via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> I agre

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

via another factory > method, however. > > Hmm. That sounds workable and simpler, definitely. > > Sorry if sounds a little rambled, don't have access to a computer for the > rest of the day so typing this all up on my phone! > > On Jun 11, 2017, at 1:39 PM, Gor

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

t; Nothing would stop you from returning a value initialized via another factory > method, however. > > Sorry if sounds a little rambled, don't have access to a computer for the > rest of the day so typing this all up on my phone! > > On Jun 11, 2017, at 1:39 PM, Gor Gyolchany

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

I agree, this makes focusing on the right types of changes much easier and helps us avoid turning Swift into an incoherent conglomeration of random use-cases (*cough*, C#, *cough*). Now, the question is: when will be the time to officially push the factory initializers proposal and which stage

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

m/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md >>>>>>> >>>>>>> <https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md> >>>>>>>> On Jun 10, 2017, at 12:43 PM, Gor Gyolcha

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

I was playing around with Swift's mysterious Builtin module, accessible via the `-parse-stdlib` compiler flag and I noticed a builtin primitive that causes a fatal error if the branch it's in is not optimized away. This seems like an opportunity for a much more powerful "this place is not

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

e can merge the second part of my >>>>>>> proposal (the `indirect init`) into your one and refine and consolidate >>>>>>> the prerequisite proposal (about returning from `init` and possibly >>>>>>> in-place member initializers) and

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

gt;>>>>>> On Jun 10, 2017, at 12:43 PM, Gor Gyolchanyan <g...@gyolchanyan.com >>>>>>>> <mailto:g...@gyolchanyan.com>> wrote: >>>>>>>> >>>>>>>> Hi, Riley! >>>>>>&

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

mplicitly `indirect` because of the previous >>>>>>>> fact? >>>>>>>> init() { … } >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> >>&g

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

t followed up on it recently. In the >>>>>> time since last working on it, I came to my own conclusion that rather >>>>>> than focusing on factory initialization, the overall initialization >>>>>> process should be simplified, which I’m

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

t;>>>>>> in-place member initializers) and bunch them up into a proposal cluster >>>>>>> (the way swift coders did). >>>>>>> Feel free to tear out any chunks from my proposal, while I think about >>>>>>&g

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

ntax.  >>>>>> >>>>>>> On Jun 10, 2017, at 8:36 PM, Riley Testut <rileytes...@gmail.com >>>>>>> <mailto:rileytes...@gmail.com>> wrote: >>>>>>> >>>>>>> Hi Gor  >>>>>&

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

of Swift 3 or 4 I haven’t followed up on it recently. In the >>>>>> time since last working on it, I came to my own conclusion that rather >>>>>> than focusing on factory initialization, the overall initialization >>>>>> proces

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

t;>>> >>>> <https://github.com/apple/swift-evolution/pull/247/commits/58b5a93b322aae998eb40574dee15fe54323de2e> >>>> Originally I used the “factory” keyword, but I think your “indirect” >>>> keyword may be a better fit (since it has preceden

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

gt;> Here’s my proposal for reference: >>>>> https://github.com/apple/swift-evolution/pull/247/commits/58b5a93b322aae998eb40574dee15fe54323de2e >>>>> >>>>> <https://github.com/apple/swift-evolution/pull/247/commits/58b5a93b322aae998eb40574dee15fe54323de2e

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

anguage and is >>> not limited to “just” being about factory initialization). To divide your >>> proposal up into smaller pieces for review, maybe we could update my >>> proposal to use your indirect keyword, and then start a separate >>> to

Re: [swift-evolution] [Pitch] Introduction of `weak/unowned` closures

If weak closures ever become a thing, I do think that the implicit strong promotion of the closure's captures should never happen and instead, the closure should be manually optional-unwrapped before it's called, so that the existing safety guarantees of weak object references would persist. >

Re: [swift-evolution] [Pitch] Introduction of `weak/unowned` closures

I don't think it's a good idea to make the `weak`-ness of the closure part of the type system. The current approach to `weak/unowned` is that it's a storage class that applies to the variable, not the value. This makes sense because you don't *use* a weak reference, you only *store* it weakly.

Re: [swift-evolution] [Pitch] Introduction of `weak/unowned` closures

The benefit that I can see here is the ability to guarantee memory safety on API level, by way of specifying weak closure members. Previously, there way no conceivable way of knowing that because a closure can essentially capture whatever it wants (even the very object it's stored in), so this

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

> smaller chunks may be better for the process. > > Let me know what you think! > > Riley > > >> On Jun 10, 2017, at 3:33 AM, Gor Gyolchanyan via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: &g

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

Love it! Except I'd add `warning` as well. > On Jun 10, 2017, at 8:15 PM, Daryle Walker via swift-evolution > wrote: > > Unconditional Error Messages > Proposal: SE- > Authors: Daryle Walker , Author 2 >

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

t; >> On Jun 9, 2017, at 2:42 PM, Gor Gyolchanyan via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> My answer to `inout` is to promote it to a full-fledged "storage class" (in >> C terminology) and allow normal variables to be `ino

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

m my iPhone >>> >>> On 10 Jun 2017, at 12:04, Gor Gyolchanyan <g...@gyolchanyan.com >>> <mailto:g...@gyolchanyan.com>> wrote: >>> >>>> Not much, I think. The `where` clause already exists, conditional `let` >>>> and `var` binding alr

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

anyan.com>> wrote: >> >>> Not much, I think. The `where` clause already exists, conditional `let` and >>> `var` binding already exists. It'd take loosening up conditional binding >>> rules a bit and expanding the lexical structure to include `let` and `var`

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

nd expanding the lexical structure to include `let` and `var` >> bindings in `repeat`. >> >>> On Jun 10, 2017, at 2:01 PM, Goffredo Marocchi <pana...@gmail.com >>> <mailto:pana...@gmail.com>> wrote: >>> >>> Quite interesting :), what impact wo

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

chi <pana...@gmail.com> wrote: > > Quite interesting :), what impact would it have on the compiler? > > Sent from my iPhone > > On 10 Jun 2017, at 11:46, Gor Gyolchanyan via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org

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

I think a better way of achieving this would be to use the already existing `where` keyword in loops. The way it works right now is as follows: let many = [1, 2, 3, 4, 5] for each in many where each % 2 == 0 { print("found an even number: \(each)") } Unfortunately, unlike all other

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

t;>>>> In case of factory initializers, the much discussed `factory init` syntax >>>>> could completely flip this logic, but making the initializer essentially >>>>> a static function that returns an object. In this case the initializer >>>>

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

forming compiler-magic structure, which would also become part of the type system and alleviate the problem. > On Jun 9, 2017, at 11:07 PM, David Sweeris <daveswee...@mac.com> wrote: > >> >> On Jun 9, 2017, at 8:12 AM, Gor Gyolchanyan via swift-evolution >>

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

e a delegating initializer >>>> call in a factory initializer >>>>if weCool { >>>>return MyCoolImpl() >>>>} else { >>>>return MyUncoolImpl() >>>>} >>

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

PM, Gwendal Roué <gwendal.r...@gmail.com> wrote: > > >> Le 9 juin 2017 à 17:12, Gor Gyolchanyan via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit : >> >>> >>> So I wonder if any of you

Re: [swift-evolution] Introduction of OrderedSet

This sounds awesome to me, except I'd take it a bit further and bring this idea to its logical conclusion: creating concrete type subtypes. Take, for example the CGFloat, which is a struct, that's essentially a subtype of Double. Seems like what you actually want is to create a subtype of

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

> > So I wonder if any of you have had any thoughts about what Swift's > parentheses-related future (or evolutionary baggage) will be? > I really wish swift used the concept of tuples **exclusively** for all purposes that involve parentheses, as well as dividing tuples into two categories: -

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

ization currently is only possible with #2 (as >>> in `self.member = value`), which could be extended in a non-factory >>> initializer to be initializable in-place like this: >>> >>> self.member.init(...) >>> >>> This would complim

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

u <xiaodi...@gmail.com >>> <mailto:xiaodi...@gmail.com>> wrote: >>> >>> If `self` is not of type `inout Self?`, then what is the type of `self` >>> such that you may assign it a value of `nil`? >>> >>> It certainly cannot be o

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

fferent meaning. >> >> Could `self` be of type `inout Self!`? Now that implicitly unwrapped >> optionals are no longer their own type, I’m not sure that’s possible. But >> even if it were, that seems unintuitive and potentially error-prone. >> >> So I think

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

ut Self?`, because the only place it can be `nil` is the place > it cannot be accessed any more. > > >> On Jun 9, 2017, at 7:45 AM, Greg Parker <gpar...@apple.com >> <mailto:gpar...@apple.com>> wrote: >> >> >>> On Jun 8, 2017, at 5:09 AM, G

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

n 8, 2017, at 5:09 AM, Gor Gyolchanyan via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> 1. Arbitrary `self` Assignments In Intializers >> >> The first ideas is to allow `self = nil` inside failable in

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

instead of >>> assigning it to a UIViewController they nest it in another container view, >>> which is not what it’s meant for in the first place. Factory initializer >>> could solve this issue by simply assigning the instance created from a nib >>> file to self.

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

in the first place. Factory initializer could solve this issue > by simply assigning the instance created from a nib file to self. The nested > view hierarchy would disappear and it won’t be that much of an abuse anymore. > > > > > -- > Adrian Zubarev > Sent with A

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

To clarify further about DefaultInitializable: An uninitialized variable of a DefaultInitializable type will *only* have its `init()` called if it's accessed before being initialized manually. This will ensure that the variable will never be initialized twice. > On Jun 8, 2017, at 6:20 PM,

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

Yeah, it's just a small syntactic sugar that doesn't change the current behavior at all, it merely makes initialization syntax more uniform and consistent. Also, something just occurred to me: When we're dealing with convenience initializers, there's the syntax `self.init(...)`, wouldn't it

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

initializer which the member is being initialized in. This guarantees that this member is either initialized, or the failable initializer returns nil immediately. > On Jun 8, 2017, at 5:19 PM, David Sweeris <daveswee...@mac.com> wrote: > > >> On Jun 8, 2017, at 05:09, Gor

[swift-evolution] [Proposal] Uniform Initialization Syntax

Disclaimer: I do realize that any of the following ideas may have been discussed before and/or there might be a good reason for their lack of implementation, so please go easy in me.  1. Arbitrary `self` Assignments In Intializers The first ideas is to allow `self = nil` inside failable

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

That's horrible news for anyone that uses generic higher-order functions. I think a proper solution to the generic problem should be in place before these breaking changes are made. > On May 2, 2017, at 1:35 PM, Vladimir.S <sva...@gmail.com> wrote: > >> On 02.05.2017 8:17, G

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

One major thing to keep in mind is how exactly will it behave in generic contexts. As a similar example, if you can do this: func foo(pass parameter: A, to closure: (A) -> B) -> B { closure(parameter) } func bar(one: Int, two: Double, three: String) { print(“\(one) \(two)

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

>>>>> <mailto:rodney.bro...@icloud.com>> wrote: >>>>> >>>>> The problem I see with your argument is that the core reason why the >>>>> optional cast failed is actually there: It was an optional value, and you >>>>> f

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

of the >>>> error. >>>> >>>> If we plumbed our code with a tonne of errors saying “why this is >>>> optional, and why it is null” then we are practically making every >>>> optional an error in the case of nil, which is completely illogi

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

ly making every optional an error >>> in the case of nil, which is completely illogical considering that nil >>> could be a completely legitimate case (especially in the case of >>> not-implicitly-unwrapped optionals). >>> >>> Optional is a wrapper for "value

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

e. The optional chaining, if-let >>>>> statements and all other ways one might try to handle an optional value >>>>> do not fundamentally require lack of error information. >>>>> The error handling mechanism, on the other hand, does not concer

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

e) and error handling (always manually >> throwing an error after manual checks). >> The aforementioned suggestion about how to do that is indeed faulty, as >> pointed out by Robert Widmann, but the problem is still valid, in my opinion. >> >> I'd highly recommend taking s

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

me thing as an optional, and I think you’re conflating > the two ideas. > > - Rod > > >> On 1 May 2017, at 5:58 pm, Gor Gyolchanyan via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I have read

  1   2   >