> On Aug 2, 2017, at 5:56 PM, Karl Wagner <razie...@gmail.com> wrote:
>> On 31. Jul 2017, at 21:09, John McCall via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>> On Jul 31, 2017, at 3:15 AM, Gor Gyolchanyan <gor.f.gyolchan...@icloud.com
>>> <mailto:gor.f.gyolchan...@icloud.com>> wrote:
>>>> On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>
>>>>> On Jul 30, 2017, at 11:43 PM, Daryle Walker <dary...@mac.com
>>>>> <mailto: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.
>
> Do we really want to make that guarantee about heap/stack allocation? C99’s
> VLAs are not very loop-friendly:
>
> echo "int main() {
> for(int i = 0; i<1000000; i++) {
> int myArray[i * 1000]; myArray[0] = 32;
> }
> return 0;
> }" | clang -x c - && ./a.out
>
> Segmentation Fault: 11
>
> C compilers also do not inline code with VLAs by default. If you force it,
> you expose yourself to possible stack overflows:
>
> echo "static inline void doSomething(int i) {
> int myArray[i * 1000]; myArray[0] = 32;
> }
> int main() {
> for(int i = 0; i<1000000; i++) {
> doSomething(i);
> }
> return 0;
> }" | clang -x c - && ./a.out
>
> Segmentation Fault: 11
>
> I wouldn’t like us to import these kinds of issues in to Swift
We probably would not make an absolute guarantee of stack allocation, no.
John.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
