> On Jul 31, 2017, at 1:37 PM, Gor Gyolchanyan via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>>> On Jul 31, 2017, at 11:23 PM, John McCall <rjmcc...@apple.com> wrote:
>>>
>>>
>>>> On Jul 31, 2017, at 4:00 PM, Gor Gyolchanyan
>>>> <gor.f.gyolchan...@icloud.com> wrote:
>>>>
>>>>
>>>>> On Jul 31, 2017, at 10:09 PM, John McCall <rjmcc...@apple.com> wrote:
>>>>>
>>>>>> On Jul 31, 2017, at 3:15 AM, Gor Gyolchanyan
>>>>>> <gor.f.gyolchan...@icloud.com> 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 <dary...@mac.com> 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 objects at run
>>>>>> time. It already has to do that for generic types and types with
>>>>>> resilient members. That does, of course, have performance consequences,
>>>>>> and those performance consequences might be unacceptable to you; but the
>>>>>> fact that we can handle it means that we don't ultimately require a
>>>>>> semantic concept of a constant expression, except inasmuch as we want to
>>>>>> allow users to explicitly request guarantees about static layout.
>>>>>
>>>>> Doesn't this defeat the purpose of generic value parameters? We might as
>>>>> well use a regular parameter if there's no compile-time evaluation
>>>>> involved. In that case, fixed-sized arrays will be useless, because
>>>>> they'll be normal arrays with resizing disabled.
>>>>
>>>> You're making huge leaps here. The primary purpose of a fixed-size array
>>>> feature is to allow the array to be allocated "inline" in its context
>>>> instead of "out-of-line" using heap-allocated copy-on-write buffers.
>>>> There is no reason that that representation would not be supportable just
>>>> because the array's bound is not statically known; the only thing that
>>>> matters is whether the bound is consistent for all instances of the
>>>> container.
>>>>
>>>> That is, it would not be okay to have a type like:
>>>> struct Widget {
>>>> let length: Int
>>>> var array: [length x Int]
>>>> }
>>>> because the value of the bound cannot be computed independently of a
>>>> specific value.
>>>>
>>>> But it is absolutely okay to have a type like:
>>>> struct Widget {
>>>> var array: [(isRunningOnIOS15() ? 20 : 10) x Int]
>>>> }
>>>> It just means that the bound would get computed at runtime and,
>>>> presumably, cached. The fact that this type's size isn't known statically
>>>> does mean that the compiler has to be more pessimistic, but its values
>>>> would still get allocated inline into their containers and even on the
>>>> stack, using pretty much the same techniques as C99 VLAs.
>>>
>>> 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 benefit from this and would finally be able to become
>>> true value types.
>>
>> To be clear, it's not obvious that using an inline array is always a good
>> move for performance! But it would be a tool available for use when people
>> felt it was important.
>
> That's why I'm trying to push for compile-time execution system. All these
> problems (among many others) could be designed out of existence and the
> compiler would be incredibly simple in the light of all the different
> specific features that the community is asking for. But I do feel your urge
> to avoid inventing a bulldozer factory just for digging a hole in a sandbox.
> It doesn't have to be relied upon by the type checker or generic resolution
> mechanism. It would be purely auxiliary.
FWIW, if we were having this conversation before maintaining source
compatibility was such an important goal, I'd be far more willing to go along
with just getting a feature implemented so that we can play now and tweak the
design later. As it is, though — and even without that compatibility goal —
realistically speaking, it'll be a year+ before anything major that we approve
now is likely to make its way into an official toolchain. There's no need to
rush the process, not until we near the end of the Swift 5 proposal timeframe.
Although I will give my +1 for having this discussion being declared in-scope
for a Swift 5.
> But that would single-handedly move a large chunk of the compiler into stdlib
> and a huge portion of various little incidental proposals would fade away
> because they can now easily be implemented in Swift for specific purposes.
Getting rid of as much "compiler magic" as possible is one of Swift's goals. If
soneobe though of a way to move the grammar spec itself into the stdlib, I
think there are some of us who'd support that. (To be clear, while I think
that'd be "winter-storm on Pluto"-cool, I'm not sure it'd actually be a good
idea at this time... seems like that belongs, if anywhere, in a macro system
proposal, which IMHO would be premature for quite a while yet.)
- Dave Sweeris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
