[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 metaprogra

Re: [swift-evolution] Moving from Swift 2 to 4

On Jul 26, 2017, at 5:37 AM, Jonathan Hull via swift-evolution wrote: > > Is there a reason why the migration only applies to Swift 3? I have some > older files which I haven’t gotten around to upgrading until now, and Xcode > Beta says I need to migrate them with an older version of Xcode.

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

I thought limiting the keywords to the ones explicitly defined for this purpose would solve the problem of overcomplicating the parser. Just to be clear: I do *not* propose replacing punctuation-based operators with identifier-based ones, the ideas was purely additive. But I do see the problem no

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

> On Jul 31, 2017, at 9:54 PM, Xiaodi Wu via swift-evolution > wrote: > On Mon, Jul 31, 2017 at 11:45 AM, Félix Cloutier > wrote: > >> Sure, and hence my point: suppose now `foo` is a function in the stdlib, and >> the stdlib authors have annotated the function

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

On Mon, Jul 31, 2017 at 9:11 PM, Xiaodi Wu wrote: > So, this has been discussed before on the list many times in the past. The > core team has stated that their preferred process for this is to have > individuals write their own libraries, get real-world adoption, then (as > consensus emerges) pr

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

> On Jul 31, 2017, at 11:29 PM, Félix Cloutier wrote: > No, this is a misunderstanding: I mean "you" as yourself, not "you" as the > compiler. As far as I know, given a type variable, as in `let foo: > NSObject.Type = NSArray.self`, you (the developer) can't use `foo` to > instantiate a generic

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

No, this is a misunderstanding: I mean "you" as yourself, not "you" as the compiler. As far as I know, given a type variable, as in `let foo: NSObject.Type = NSArray.self`, you (the developer) can't use `foo` to instantiate a generic type. The question stands again: are there any specific reaso

Re: [swift-evolution] [Idea] Creating an enums as a sum of multiple other enums

That solution seems way too verbose, and also not exactly type safe because you must handle optionals in addition to any new cases that arise, which are silently handled by the default case. To Xiaodi: is this really just value subtyping? Seems like it would also require multiple inheritance fo

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

> On Jul 31, 2017, at 7:23 PM, Daryle Walker via swift-evolution > wrote: > > When coming up with new array interfaces, I had some array to/from tuple > conversion functions: > > func array(from: (T, …U)) -> [1 + #countOf(U) ; T] allwhere U == T > > The problem is going the other way: > > f

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

When coming up with new array interfaces, I had some array to/from tuple conversion functions: func array(from: (T, …U)) -> [1 + #countOf(U) ; T] allwhere U == T The problem is going the other way: func tuple(from: [N; T]) -> ??? The tuple will be a bunch of “T,” but the count mechanically add

Re: [swift-evolution] [Idea] Creating an enums as a sum of multiple other enums

Not a response to the core of this, but to the motivating example: Sectioned (or multi-sorted in other cases) ASTs can also be represented by a singly-sorted AST and views over top enum UnaryOperatorView { case not } enum BinaryOperatorView { case and case or } enum BooleanLiteralView {

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

On Mon, Jul 31, 2017 at 11:45 AM, Félix Cloutier wrote: > > Sure, and hence my point: suppose now `foo` is a function in the stdlib, > and the stdlib authors have annotated the function so that it is `func > foo(arr: fixed [Int])`. Then, any user who writes `var array = ...` could > benefit from

Re: [swift-evolution] [Idea] Creating an enums as a sum of multiple other enums

I think what you're asking for here is essentially some sort of (or special case of) value subtyping, a topic near and dear to many. On Mon, Jul 31, 2017 at 7:43 PM, Ahmad Alhashemi via swift-evolution < swift-evolution@swift.org> wrote: > I’ve been writing an interpreter in Swift and have been

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

> On Jul 31, 2017, at 8:38 PM, Robert Widmann wrote: > >> On Jul 31, 2017, at 4:08 PM, Daryle Walker > > wrote: >> >>> On Jul 31, 2017, at 1:45 PM, Robert Widmann >> > wrote: >>> >>> Additionally, the use of inheritance in alternate definitions

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

> On Jul 31, 2017, at 2:09 PM, Gor Gyolchanyan via swift-evolution > wrote: > > So I was thinking the other day (and by "the other day" I mean "It just > occurred to me") that Swift's custom operator declaration mechanism is pretty > sweet (it's become even sweeter ever since numeric preceden

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

So, this has been discussed before on the list many times in the past. The core team has stated that their preferred process for this is to have individuals write their own libraries, get real-world adoption, then (as consensus emerges) propose their inclusion as a core library. Keep in mind that

[swift-evolution] [Idea] Creating an enums as a sum of multiple other enums

I’ve been writing an interpreter in Swift and have been finding enums incredibly useful. One feature thought that I thought would make life easier is the ability to create a super-enum that contains as its cases all the cases of its constituent enums: > enum UnaryOperator { > case not > } >

Re: [swift-evolution] Fast String Comparison From String Arrays

Hi Omar, Could you talk in a little more detail about your algorithm, including space/time complexity? It sounds interesting, but I am having trouble finding the relevant portions in the source code... Thanks, Jon > On Jul 31, 2017, at 1:26 AM, Omar Charif via swift-evolution > wrote: > >

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

> On Jul 31, 2017, at 4:08 PM, Daryle Walker wrote: > >> On Jul 31, 2017, at 1:45 PM, Robert Widmann > > wrote: >> >> As I was saying, I agree with the overall usefulness of newtype-style >> declarations, but I don’t understand why we need so much syntax for what >

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

I’d be completely in favor of this. Structs for priority queues, skiplists, trees, binary search and more sorting functions would also be on my wishlist. I think Python made a very good choice in choosing to vend separate standard modules for stuff like that instead of bloating its builtin namespa

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

PS, for what it’s worth, i am the maintainer of the language-swift-89 atom package. On Mon, Jul 31, 2017 at 8:29 PM, Taylor Swift wrote: > > > On Mon, Jul 31, 2017 at 7:20 PM, David Sweeris > wrote: > >> >> > On Jul 31, 2017, at 3:59 PM, Taylor Swift

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

On Mon, Jul 31, 2017 at 7:20 PM, David Sweeris wrote: > > > On Jul 31, 2017, at 3:59 PM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > > > I’m gonna come out and say I’m not a fan of this at all. I’m already > pretty suspicious of operator overloading, and I think sup

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

+1000 to this. > On Jul 31, 2017, at 11:22 AM, Hooman Mehr via swift-evolution > wrote: > > Maybe we need more than one level of standard library: The core (which is > most of what we have now (but maybe not all of it) and multiple opt-in > standard modules for hash functions, math, specializ

Re: [swift-evolution] Extensions

> On Jul 31, 2017, at 4:19 PM, Omar Charif via swift-evolution > wrote: > > I am a big fan of extensions, but I wonder what would happen years from now > when we start to have lots of extensions created for the primitive classes. > The problem is that we can write a String extension for examp

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

> On Jul 31, 2017, at 3:59 PM, Taylor Swift via swift-evolution > wrote: > > I’m gonna come out and say I’m not a fan of this at all. I’m already pretty > suspicious of operator overloading, and I think supporting this would make > Swift code much more difficult to read. Also, while for some

[swift-evolution] Extensions

I am a big fan of extensions, but I wonder what would happen years from now when we start to have lots of extensions created for the primitive classes. The problem is that we can write a String extension for example in any swift file in the project, the name of the file has nothing to do with th

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

> On Jul 31, 2017, at 1:45 PM, Robert Widmann wrote: > > As I was saying, I agree with the overall usefulness of newtype-style > declarations, but I don’t understand why we need so much syntax for what > should just be a pattern in Swift. Specifically, the idea of automatic > delegation of an

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

I’m gonna come out and say I’m not a fan of this at all. I’m already pretty suspicious of operator overloading, and I think supporting this would make Swift code much more difficult to read. Also, while for some reason everyone ignores this, this kind of syntax is almost impossible for text editors

Re: [swift-evolution] [Pitch][Bug?] Test for Anti-Conformance During Generics

> On Jul 31, 2017, at 1:49 PM, Robert Widmann wrote: > >> On Jul 31, 2017, at 10:34 AM, Daryle Walker via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Part of the response that closed [SR-5589] as “Won’t Do” was: >> >>> AnyObject is no longer a protocol >> >> >> Then,

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

> On Jul 31, 2017, at 5:09 PM, Gor Gyolchanyan via swift-evolution > wrote: > > So I was thinking the other day (and by "the other day" I mean "It just > occurred to me") that Swift's custom operator declaration mechanism is pretty > sweet (it's become even sweeter ever since numeric preceden

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

On Jul 31, 2017, at 12:15 AM, Gor Gyolchanyan via swift-evolution wrote: >> On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution >> wrote: >> >>> On Jul 30, 2017, at 11:43 PM, Daryle Walker wrote: >>> The parameters for a fixed-size array type determine the type's >>> size/stride,

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

Sent from my iPad > On Jul 31, 2017, at 2:09 PM, Gor Gyolchanyan via swift-evolution > wrote: > > So I was thinking the other day (and by "the other day" I mean "It just > occurred to me") that Swift's custom operator declaration mechanism is pretty > sweet (it's become even sweeter ever si

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

> On Jul 31, 2017, at 1:37 PM, Gor Gyolchanyan via swift-evolution > wrote: > > >>> On Jul 31, 2017, at 11:23 PM, John McCall wrote: >>> >>> On Jul 31, 2017, at 4:00 PM, Gor Gyolchanyan wrote: > On Jul 31, 2017, at 10:09 PM, John McCall wrote: > >> On J

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

So I was thinking the other day (and by "the other day" I mean "It just occurred to me") that Swift's custom operator declaration mechanism is pretty sweet (it's become even sweeter ever since numeric precedence values were replaced with purely relativistic precedence trees). There are currently

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 >> > wrote: >>> On Jul 31, 2017, at 4:00 PM, Gor Gyolchanyan >

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

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

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 >> > wrote: >>> On Jul 31, 2017, at 3:15 AM, Gor Gyolcha

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

> On Jul 31, 2017, at 4:00 PM, Gor Gyolchanyan > wrote: > > >> On Jul 31, 2017, at 10:09 PM, John McCall > > wrote: >> >>> On Jul 31, 2017, at 3:15 AM, Gor Gyolchanyan >> > wrote: On Jul 31, 2017, at 7:10 AM, John McCall via

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, at 11:43 PM, Daryle Walker wrote: The parameters for a fixed-size array

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

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

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

> On Jul 31, 2017, at 3:58 AM, Félix Cloutier wrote: > It seems to me that this applies just the same to type generic parameters. > Are there any reason that you can't instantiate a generic type at runtime, or > is it just because the need is not as evident as it would/could be with > non-type

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

Maybe we need more than one level of standard library: The core (which is most of what we have now (but maybe not all of it) and multiple opt-in standard modules for hash functions, math, specialized data structures, etc. > On Jul 31, 2017, at 11:10 AM, Taylor Swift wrote: > > I’m not sure why

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

I’m not sure why only the stdlib is inlineable and specializable, but I believe it has something to do with ABI. I’m not an ABI expert though. I strongly disagree that a Swift Math library should be delegated to a third party. Math is “common” enough that there should really only be one “standard”

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

I know. I hear you. I have some special arrangmnents to keep such things manageable, and I am not happy about how things stand right now. What I am hoping to open up stdlib special compiler mode to other (low-level) libraries and also letting such libraries gain optimizations similar to stdlib

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

Isn’t the point of standard inlineable library module to prevent the need to copy and paste code like this into every project? Currently I have a “math.swift” file I copy and paste into all of my projects, and since I occasionally update it, there exists about 15 different versions of it floating a

Re: [swift-evolution] [Pitch][Bug?] Test for Anti-Conformance During Generics

> On Jul 31, 2017, at 10:34 AM, Daryle Walker via swift-evolution > wrote: > > >> On Jul 31, 2017, at 1:33 AM, Daryle Walker > > wrote: >> >>> On Jul 31, 2017, at 1:19 AM, Xiaodi Wu >> > wrote: >>> >>> Daryle, this discussion has indeed ta

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

I prefer an approach that preserves how I am used to seeing math expressions. I use this myself: protocol FloatingPointMath: FloatingPoint { static func sqrt(_ value: Self) -> Self static func sin(_ value: Self) -> Self static func cos(_ value: Self) -> Self static func tan(_ val

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

(Excuse me, my last reply was sent prematurely) As I was saying, I agree with the overall usefulness of newtype-style declarations, but I don’t understand why we need so much syntax for what should just be a pattern in Swift. Specifically, the idea of automatic delegation of an interface is an

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

I agree with the overall usefulness of newtype-style ( > On Jul 29, 2017, at 4:01 PM, Daryle Walker via swift-evolution > wrote: > > Proposal at > >, > up

Re: [swift-evolution] [Pitch][Bug?] Test for Anti-Conformance During Generics

> On Jul 31, 2017, at 1:33 AM, Daryle Walker wrote: > >> On Jul 31, 2017, at 1:19 AM, Xiaodi Wu > > wrote: >> >> Daryle, this discussion has indeed taken place before. One good place to >> start is the Google result for "swift evolution non-conformance". > > I adde

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

> On Jul 31, 2017, at 1:29 PM, Taylor Swift via swift-evolution > wrote: > > Also squareRoot() should be moved to the Math module if it is ever created. No; square root is an IEEE-754 required basic operation, just like addition or multiplication. It is part of the FloatingPoint protocol for t

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

On Mon, Jul 31, 2017 at 1:23 PM, Adrian Zubarev < adrian.zuba...@devandartist.com> wrote: > I’m not sure how I would feel about this. To be honest I’d avoid such > additional changes from the stdlib, because they really don’t belong there. > Instead some `Math` module/package would be a better fit

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

On Mon, Jul 31, 2017 at 1:19 PM, Benjamin Spratling wrote: > 1) Why would cos, sin, ln, tan, asin, acos, atan and exp be functions and > not computed properties? > 2) For people who uses these features on paper and text books, writing > them as what we call global functions is standard. Seeing

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

I’m not sure how I would feel about this. To be honest I’d avoid such additional changes from the stdlib, because they really don’t belong there. Instead some `Math` module/package would be a better fit than clustering everything into stdlib until we end up also adding UI stuff. Furthermore, I

Re: [swift-evolution] Recent change makes Swift 4 less safe.

I don’t agree with your assertions that this makes Swift “less safe” - if anything the bug that this fixed was anything but. When performing a pattern match, we expect the pattern to match the “shape” of the declaration itself. If ‘()’ was not part of that declaration, then you have no reason

[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

How would people feel about adding a protocol protocol MathFloatingPoint:FloatingPoint { func sin() -> Self func cos() -> Self func tan() -> Self func asin() -> Self func acos() -> Self func atan() -> Self func ln() -> Self func log(base:Self) -> Self func pow(

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

> Sure, and hence my point: suppose now `foo` is a function in the stdlib, and > the stdlib authors have annotated the function so that it is `func foo(arr: > fixed [Int])`. Then, any user who writes `var array = ...` could benefit from > a performance boost because the compiler will not longer

Re: [swift-evolution] [Pitch][Bug?] Test for Anti-Conformance During Generics

Indeed. I think something that is missing from the generics manifesto is that we need more type constraints. Value/reference semantics is one badly-needed distinction, but there are others, too (e.g. trivial types). There are lots of generic structures and algorithms which developers

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

On Mon, Jul 31, 2017 at 3:39 AM, Félix Cloutier wrote: > > Le 31 juil. 2017 à 00:40, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> a écrit : > > > On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution < > 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 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 on

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

> 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 one of > those optional attributes for arrays, like ownership will be fo

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

> Le 31 juil. 2017 à 00:40, Xiaodi Wu via swift-evolution > a écrit : > > > On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution > > mailto:swift-evolution@swift.org>> wr

Re: [swift-evolution] Fast String Comparison From String Arrays

The main advantage I introduce is actually no just a substring search, my main goal is to achieve high performance repeated search on the same given array of strings. I have tested my algorithm against something like spotlight for example searching for files etc … Actually my code is a bit faste

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

> On Jul 31, 2017, at 11:09 AM, Xiaodi Wu wrote: > > > On Mon, Jul 31, 2017 at 02:51 Gor Gyolchanyan > wrote: >> On Jul 31, 2017, at 10:40 AM, Xiaodi Wu > > wrote: >> >> >> On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift

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

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

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

On Mon, Jul 31, 2017 at 02:49 Goffredo Marocchi wrote: > > > Sent from my iPhone > > On 31 Jul 2017, at 08:40, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution < > swift-evolution@swift.org> wrote: > >> > O

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

It seems to me that this applies just the same to type generic parameters. Are there any reason that you can't instantiate a generic type at runtime, or is it just because the need is not as evident as it would/could be with non-type generic parameters? > Le 30 juil. 2017 à 21:10, John McCall v

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

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

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

Sent from my iPhone > On 31 Jul 2017, at 08:40, Xiaodi Wu via swift-evolution > wrote: > > >> On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution >> wrote: >> > On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution >> > wrote: >> > >> >> On Jul 30, 2017, at 11:43 PM,

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

On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution < swift-evolution@swift.org> wrote: > > On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution < > swift-evolution@swift.org> wrote: > > > >> On Jul 30, 2017, at 11:43 PM, Daryle Walker wrote: > >> The parameters for a fixed-

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 during compile-time? The compiler >> can't l