[swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)

[Trent Nadeau]

That looks great except that I would prefer (4 * Int). Having "x" as an
operator looks very odd to me, and it doesn't fit with the rest of the
language.

On Thu, Jan 28, 2016 at 8:07 PM, Erica Sadun via swift-evolution <
swift-evolution at swift.org> wrote:

> I find
>
> let values: (4 x Int) = (1, 2, 3, 4)
>
> to be adequately cromulent. I believe this approach to be:
>
> * Readable, even to someone unfamiliar with the syntax
> * The parens before the assignment suggest something to do with tuples,
> and the numbers match the arity after the assignment
> * The type is preserved in-place
> * It's compact, elegant, simple
>
> -- E
>
>
> On Jan 28, 2016, at 5:56 PM, Joe Groff via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Jan 28, 2016, at 4:04 PM, Haravikk <e-mail at haravikk.me> wrote:
>
>
> On 28 Jan 2016, at 22:37, Joe Groff via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Jan 28, 2016, at 2:36 PM, Jacob Bandes-Storch <jtbandes at gmail.com>
> wrote:
>
> I like this idea, but the syntax seems dangerously close to a call site
> for  "func *(lhs: Int, rhs: Any.Type)"  (which is obviously ill-advised,
> but it is allowed).
>
> Maybe we could take advantage of something which would be very invalid
> under the current grammar, namely (n T) rather than (n * T):
>
>    let values: (4 Int) = (1, 2, 3, 4)
>
>
> Sure, or we could lift (4 x Int) from LLVM IR's syntax.
>
>
> How about:
>
> let values:Int[4] = (1,2,3,4)
>
> While it looks a bit like a subscript, it doesn’t make sense in a type
> declaration at present, so could be a good way to define restrictions of
> this type (we could even extend it to collections later). If the similarity
> is too close then:
>
> let values:(Int[4]) = (1,2,3,4)
>
> Could work too? Just some alternatives anyway, as I like the idea.
>
>
> This kind of syntax doesn't compose well with other type productions. If
> you parse Int[N][M] naively as (Int[N])[M], then you end up with an array
> of M (array of N (Int)), which ends up subscripting in the opposite order,
> array[0..<M][0..<N]. C works around this by flipping the order of multiple
> array indices in a type declaration, so int [n][m] is really (int [m]) [n],
> but this doesn't work well for Swift, which has other postfix type
> productions—how would Int[N]?[M] parse? Choosing a prefix notation for
> fixed-sized array bounds is better IMO to avoid these pitfalls.
>
> -Joe
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Trent Nadeau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160128/f030fcc4/attachment.html>