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

Sorry for jumping late into this, about the topic of compile time execution, I raised it pretty much in the beginning of Swift being open sourced and it stills pops in my mind everytime I see Jonathan Blow use it in his language. So for my own curiosity, how feasible it is for Swift to do it with

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

on Mon Jul 31 2017, John McCall wrote: >> I see your point. Dynamically-sized in-place allocation is something >> that completely escaped me when I was thinking of fixed-size >> arrays. I can say with confidence that a large portion of >> private-class-copy-on-write value types would greatly ben

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

Imho this topic was much better than that other one ;-) — and I just realised that of metaprogramming build on top of reflection wasn't discussed in its own thread yet… I fear "constexpr" is already burned, because people associate it with things like calculating Fibonacci numbers at compile tim

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

> On Aug 6, 2017, at 11:59 PM, Daryle Walker wrote: >> On Aug 1, 2017, at 2:58 PM, John McCall > > wrote: >> >>> >>> On Aug 1, 2017, at 9:53 AM, Daryle Walker >> > wrote: >>> On Jul 31, 2017, at 4:37 PM, Gor Gyolchanyan >>>

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

> On Aug 3, 2017, at 8:20 PM, Karl Wagner via swift-evolution > wrote: > >>> The root cause, of course, is that the VLAs require new stack allocations >>> each time, and the stack is only deallocated as one lump when the frame >>> ends. >> >> That is true of alloca(), but not of VLAs. VLAs a

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

> On Aug 1, 2017, at 2:58 PM, John McCall wrote: > >> >> On Aug 1, 2017, at 9:53 AM, Daryle Walker > > wrote: >> >>> On Jul 31, 2017, at 4:37 PM, Gor Gyolchanyan >> > wrote: >>> >>> Well, yeah, knowing its size statically is not a re

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

> Le 6 août 2017 à 08:15, Karl Wagner a écrit : > >> >> On 4. Aug 2017, at 20:15, John McCall via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Aug 4, 2017, at 1:19 PM, Félix Cloutier via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> Tha

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

> On Aug 6, 2017, at 11:15 AM, Karl Wagner wrote: > > >> On 4. Aug 2017, at 20:15, John McCall via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Aug 4, 2017, at 1:19 PM, Félix Cloutier via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> Th

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

> On 6. Aug 2017, at 17:15, Karl Wagner via swift-evolution > wrote: > > let newItems_heap = newItems.backing.isAllocatedInline ? > newItems(withBacking: newItems.backing.clone()) : newItems Should, of course, be: let newItems_heap = newItems.backing.isAllocatedInline ? Array(withBacking: n

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

> On 4. Aug 2017, at 20:15, John McCall via swift-evolution > wrote: > >> >> On Aug 4, 2017, at 1:19 PM, Félix Cloutier via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> That's not a concern with the `let` case that Robert brought up, since you >> can't mutate a `let` a

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

Sorry, not sure how I missed that 😑. > On Aug 4, 2017, at 3:16 PM, Félix Cloutier wrote: > > >> Le 4 août 2017 à 11:39, Robert Bennett a écrit : >> >>> That's not a concern with the `let` case that Robert brought up, since you >>> can't mutate a `let` array at all. >>> >>> The big thing is

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

> Le 4 août 2017 à 11:39, Robert Bennett a écrit : > >> That's not a concern with the `let` case that Robert brought up, since you >> can't mutate a `let` array at all. >> >> The big thing is that unconstrained escape analysis is uncomputable. Since >> Swift array storage is COW, any function

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

> That's not a concern with the `let` case that Robert brought up, since you > can't mutate a `let` array at all. > > The big thing is that unconstrained escape analysis is uncomputable. Since > Swift array storage is COW, any function that receives the array as a > parameter is allowed to take

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

> On Aug 4, 2017, at 1:19 PM, Félix Cloutier via swift-evolution > wrote: > > That's not a concern with the `let` case that Robert brought up, since you > can't mutate a `let` array at all. > > The big thing is that unconstrained escape analysis is uncomputable. Since > Swift array storage i

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

That's not a concern with the `let` case that Robert brought up, since you can't mutate a `let` array at all. The big thing is that unconstrained escape analysis is uncomputable. Since Swift array storage is COW, any function that receives the array as a parameter is allowed to take a reference

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

I've never seen the Swift compiler put array storage on automatic storage, even for small arrays. I don't think that it has much to do with their size, though (for any array that is not incredibly large). > Le 3 août 2017 à 23:18, David Hart a écrit : > > Don’t small arrays live on the stack?

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

No, that doesn’t work. In many cases you want to mutate the elements of the array without changing its size. For example, a Camera struct which contains a matrix buffer, and some of the matrices get updated on each frame that the camera moves. The matrix buffer also stores all of the camera’s store

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

So, I’m getting into this thread kind of late, and I’ve only skimmed most of it, but… A special FSA on the stack seems like the wrong direction. Wouldn’t it make more sense to have *all* value types that don’t change in size — including `let` Arrays — live on the stack? In which case, FSA would

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

Don’t small arrays live on the stack? > On 4 Aug 2017, at 06:35, Félix Cloutier via swift-evolution > wrote: > > As far as I can tell, currently, all arrays live on the heap. > >> Le 3 août 2017 à 19:03, Robert Bennett via swift-evolution >> mailto:swift-evolution@swift.org>> a écrit : >> >>

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

As far as I can tell, currently, all arrays live on the heap. > Le 3 août 2017 à 19:03, Robert Bennett via swift-evolution > a écrit : > > Where do constant Arrays currently live? I hope the answer is on the stack, > since their size doesn’t change. > > On Aug 3, 2017, at 8:44 PM, Taylor Swif

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

> Le 3 août 2017 à 17:44, Taylor Swift via swift-evolution > a écrit : > > On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >>> >>> The root cause, of course, is that the VLAs require new stack allocations >>> each time, and the stac

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

For what it’s worth, I’d be happy with just subscripts on tuples and some form of shorthand for their size. Maybe (Float ... 5) or something like that. That would obviate the need for an attribute too. On Thu, Aug 3, 2017 at 11:48 PM, Karl Wagner wrote: > > Actually, if you do a lot of graphic

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

> Actually, if you do a lot of graphics programming like I do, the memory > layout is very, very important. Swift may not care about layout, but many > APIs that it interacts with do. > Sure; I’m well-aware of how important it can be to decide on an appropriate memory layout. I’m very much i

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

On Thu, Aug 3, 2017 at 11:17 PM, Karl Wagner wrote: > > On 4. Aug 2017, at 02:44, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > > > On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> The root cause, of course,

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

> On 4. Aug 2017, at 02:44, Taylor Swift via swift-evolution > wrote: > > > > On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >>> >>> The root cause, of course, is that the VLAs require new stack allocations >>> each time, and the

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

Where do constant Arrays currently live? I hope the answer is on the stack, since their size doesn’t change. > On Aug 3, 2017, at 8:44 PM, Taylor Swift via swift-evolution > wrote: > > > > On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution > wrote: The root cause, o

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

On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution < swift-evolution@swift.org> wrote: > > The root cause, of course, is that the VLAs require new stack allocations > each time, and the stack is only deallocated as one lump when the frame > ends. > > > That is true of alloca(), but no

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

>> >> The root cause, of course, is that the VLAs require new stack allocations >> each time, and the stack is only deallocated as one lump when the frame ends. > > That is true of alloca(), but not of VLAs. VLAs are freed when they go out > of scope. > Learned something today. Anyway, if t

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

> On Aug 2, 2017, at 6:29 PM, Karl Wagner wrote: > > >> On 3. Aug 2017, at 00:21, John McCall > > wrote: >> >> >>> On Aug 2, 2017, at 6:10 PM, John McCall via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> On Aug 2, 2017, at 5:56 PM, Karl W

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

> On 3. Aug 2017, at 00:21, John McCall wrote: > > >> On Aug 2, 2017, at 6:10 PM, John McCall via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Aug 2, 2017, at 5:56 PM, Karl Wagner >> > wrote: On 31. Jul 2017, at 21:09, John McCall via

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

> On Aug 2, 2017, at 6:10 PM, John McCall via swift-evolution > wrote: > >> On Aug 2, 2017, at 5:56 PM, Karl Wagner > > wrote: >>> On 31. Jul 2017, at 21:09, John McCall via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> On Jul 31, 2017, at 3

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

> On Aug 2, 2017, at 5:56 PM, Karl Wagner wrote: >> On 31. Jul 2017, at 21:09, John McCall via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Jul 31, 2017, at 3:15 AM, Gor Gyolchanyan >> > wrote: On Jul 31, 2017, at 7:10 AM, John

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

> On 31. Jul 2017, at 21:09, John McCall via swift-evolution > 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

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

> On Aug 2, 2017, at 12:17 PM, Félix Cloutier wrote: > `[Int x N]` solves all of the problems that I mentioned, and I'm happy with > that syntax. In fact, I'm championing its merits versus an approach that > doesn't include the number of elements. :) > > Unless I got things wrong this entire ti

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

> The bound value is still fundamentally part of the type of the variable; it's > just that the actual value is not known statically. I don't know enough about the internals to prove such a conclusion ;-), but my intuition said that this would be possible… My intuition also says that this might

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

`[Int x N]` solves all of the problems that I mentioned, and I'm happy with that syntax. In fact, I'm championing its merits versus an approach that doesn't include the number of elements. :) Unless I got things wrong this entire time, the proposed spelling

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

> On Aug 2, 2017, at 11:44 AM, Félix Cloutier via swift-evolution > wrote: > > >> Le 31 juil. 2017 à 18:54, Xiaodi Wu > > a écrit : >> It doesn't allow you to specify the size of the array, it's just a promise >> that the array is some immutable size. For instance,

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

> Le 31 juil. 2017 à 18:54, Xiaodi Wu a écrit : > It doesn't allow you to specify the size of the array, it's just a promise > that the array is some immutable size. For instance, a `fixed [CGFloat]` > would be a terrible type to represent a vector, but a FixedSizeArray 4> would be appropriate,

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

> On Aug 1, 2017, at 3:36 PM, Jean-Daniel via swift-evolution > wrote: > >> I disagree. Most of the standard library is in protocols and small generic >> wrapper structures, which are prime candidates for compile-time evaluation. >> Even if Foundation has to be dropped (which is actually not

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

> Le 30 juil. 2017 à 12:23, Gor Gyolchanyan via swift-evolution > a écrit : > >> On Jul 30, 2017, at 1:03 PM, Daniel Vollmer via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Hello, >> >>> On 30. Jul 2017, at 08:52, Gor Gyolchanyan via swift-evolution >>> mailto:swift-e

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

> On Aug 1, 2017, at 9:53 AM, Daryle Walker 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 Gyol

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

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,

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

Sent from my iPhone > On Jul 31, 2017, at 23:47, John McCall via swift-evolution > wrote: > > I disagree; it seems to me that a homogeneous fixed-size sequence is its own > concept, and there isn't any natural link between that concept and that of a > tuple. The elements of a tuple are inde

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

>> I expect that conforming homogeneous tuples to Collection and enabling >> subscripting is simply a matter of time. > > I disagree; it seems to me that a homogeneous fixed-size sequence is its own > concept, and there isn't any natural link between that concept and that of a > tuple. I'm rel

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

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

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

> On Jul 30, 2017, at 11:43 PM, Daryle Walker wrote: > The parameters for a fixed-size array type determine the type's size/stride, > so how could the bounds not be needed during compile-time? The compiler can't > layout objects otherwise. Swift is not C; it is perfectly capable of laying out

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

The parameters for a fixed-size array type determine the type's size/stride, so how could the bounds not be needed during compile-time? The compiler can't layout objects otherwise. Or do you mean that the bounds are integer literals? (That's what I have in the design document now.) Sent from

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

> On Jul 29, 2017, at 7:01 PM, Daryle Walker via swift-evolution > wrote: > The “constexpr” facility from C++ allows users to define constants and > functions that are determined and usable at compile-time, for compile-time > constructs but still usable at run-time. The facility is a key step f

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

Is there any reason that constexpr couldn’t be inferred? Wherever you need something to be compile time constant — value-based generics, rawValue enum cases, etc — the compiler could make sure that the value was known at compile time, and if not then raise an error. Basically, assume everything

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

> On Jul 30, 2017, at 5:34 PM, Tino Heth <2...@gmx.de> wrote: > >> If you read my reply to Daniel Vollmer, you’ll find that we’re thinking >> about the exact same thing. > Good to hear — read that post later, but I guess repeating doesn't hurt here: > People still talk about macros... ;-) > >

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

> If you read my reply to Daniel Vollmer, you’ll find that we’re thinking about > the exact same thing. Good to hear — read that post later, but I guess repeating doesn't hurt here: People still talk about macros... ;-) >> So while I think they’re both great features to have, I assume the core

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

On Jul 30, 2017, at 10:03 AM, Gor Gyolchanyan via swift-evolution wrote: > 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

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

> On Jul 30, 2017, at 9:29 PM, Christopher Kornher wrote: > > I am not sure that macros and annotations would be good, either. It may be > impossible to avoid them, given Swift’s goal of “world domination”. Both > features are very useful in certain applications. I’d argue that exposing swift’

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

I am not sure that macros and annotations would be good, either. It may be impossible to avoid them, given Swift’s goal of “world domination”. Both features are very useful in certain applications. We could continue to use custom tools like Cog and Sourcery when we need to, or standardize and b

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

For completeness: I forgot to mention that I have been meaning to check-out Sourcery, which is possibly a more “Swifty” tool. I use Cog’s file-scope extensively, and it is unclear to me if that is a feature of Sourcery https://github.com/krzysztofzablocki/Sourcery OK, now I am sure that someone

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

I don’t think a Cog-like or Gyb-like macro system would be good. That’s essentially a preprocessor and we all know how that worked out for C. The only a code-generation feature can exist in a safe language like Swift is by making it a first-class citizen as described previously. I’m not sure whe

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

I assume that the planned “hygienic macro” facility, if it has access to metadata, or “annotations", could be used for these sorts of meta tasks, . This is slightly off-topic, but I hope that there is a way for macros to be fully expanded and debuggable (and even formatted). I use Cog with Swift

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 g

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

> more elaborate compile-time facilities, which would also provide extremely > powerful meta programming features That's an interesting twist — but whenever you put a "meta" somewhere, things tend to get complicated, and people end up with different associations to the topic… ;-) I took a brief

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

> On Jul 30, 2017, at 1:03 PM, Daniel Vollmer via swift-evolution > wrote: > > Hello, > >> On 30. Jul 2017, at 08:52, Gor Gyolchanyan via swift-evolution >> wrote: > > [snip] > >> This is a huge undertaking, but if we split it in two parts: "executing at >> compiletime" and "exposing swift

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

Hello, > On 30. Jul 2017, at 08:52, Gor Gyolchanyan via swift-evolution > wrote: [snip] > This is a huge undertaking, but if we split it in two parts: "executing at > compiletime" and "exposing swift’s frontend”, this could surely be done by > Swift 5. From all the ideas that I’ve had or see

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

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

The “constexpr” facility from C++ allows users to define constants and functions that are determined and usable at compile-time, for compile-time constructs but still usable at run-time. The facility is a key step for value-based generic parameters (and fixed-size arrays if you don’t want to be