what should we use { } for?

[JeffBezanson]

@jakebolewski had this very good idea today.

Our tuple types are currently quite ugly since they are not distinguished from tuple values. This causes various problems in the system, such as whether to treat () as a type. We also need to specialize tuple representations (e.g. storing (Float64,Float64) as compactly as a Complex128), which means tuple types will need to contain extra layout information that tuple values do not have. This would also eliminate the need for a fancy predicate to test whether some tuple is a type.

It would be quite easy to use Union{...} for union types, and then all types would be constructed with curly braces 👍.

This change also makes it easy to use (x, y...) for splatting in tuple construction (#4869), and {Int...} for varargs types.

All current uses of { } can be replaced with Any[ ] or (Any=>Any)[ ], so that syntax is effectively up for grabs. The wastefulness of the current { } has been discussed elsewhere. I admit this proposal feels slightly wasteful as well, but it could be worth it for solving various problems in the type system and making type syntax highly consistent. On the whole, I am in favor of this idea.

[quinnj]

I think this would be a great change. More consistency with { } and types. I think changing [] to default to Any[] should go along with this too.

[garborg]

👍

[IainNZ]

I like it a lot

{Vector{Int}, Int}
Union{Vector{Int}, Int}
foo{T<:Union{Int,Float64}(x::Vector{T}, y::{Int,Int}) = print(T," ",y)

All seem pretty human-parseable. The (,) thing for tuple types has always been a big confusing for me.

[jiahao]

Two other things from today's discussion:

1. Currently typeof has two fixed points. typeof(X) == X has the solution X = DataType, but also X = ().
2. If tuples are product types, then (as discussed in Extraneous ambiguity warning: (MyType{T},T) vs (T,MyType{T}) #1631) finite-length tuples of the form (T1, ..., T2, None, T3, ..., T4) should be reducible to just None, but they aren't right now. Currently there is a single tuple constructor for value tuples and type tuples, which makes it difficult to implement such a reduction rule. With this proposed change we could do these kinds of checks and simplifications when constructing tuple types.

[johnmyleswhite]

I like this.

If we make this change and also change [] to not do automatic splatting, will we have no syntax for arrays with automatic splatting? I'd like that, so I'm just wondering.

[garborg]

👍 to that, too.

[simonster]

@jiahao I think typeof currently has an infinite number of fixed points, since typeof(((),)) == ((),), typeof((((),),)) == (((),),), etc.

[toivoh]

• a lot for distinguishing tuples from tuple types.

However, I think there's many legitimate uses contending for the braces. An alternative would be to use Tuple{Int, String} etc.

+1 for Union{} as well, that has always felt inconsistent (though maybe it isn't).

[kmsquire]

I think I finally stopped typing Union{Int, Uint} about a week ago....

[catawbasam]

+1 for Tuple{Int, String} and Union{} for being explicit and obviously describing types.

[JeffBezanson]

I think we could implement Tuple{Int,String} first, and later remove the Tuple part if it is too annoying.

[StefanKarpinski]

I think I finally stopped typing Union{Int, Uint} about a week ago....

LOL.

@jiahao, @simonster – there is a free monoid of fixed points with () and DataType as generators. With this change, there would only be DataType, which seems a little more sane. Not that fixed points of the typeof operator are particularly problematic, but it does seem simpler.

I'd be ok with this change, although it does really feel a bit wasteful. The idea of making { } entirely "typey" is appealing. I kind of wish this change had just a little more umph to push it over the edge...

[JeffBezanson]

I know what you mean. We do need at least Tuple{ }; otherwise tuples will never quite be sane.

[jiahao]

Closed by #10380

[jakebolewski]

I still hold out hope that this will be the final syntax.

[JeffBezanson]

I agree. I'm 100% in favor of this. I'm tired of typing "Tuple", and hopefully soon everybody else will be too.

[tkelman]

Based on the deprecation policy, we should really leave {} as its former deprecated meaning for at least one release. So I don't think this syntax change needs to be resolved until early in 0.5-dev.

[JeffBezanson]

In that case, we might want to continue allowing tuples of types in various places. Writing code_typed(foo, Tuple{ ... }) gets old.

[StefanKarpinski]

Can't you do that just by writing methods that convert tuples to tuple types?

[JeffBezanson]

For 1.0, we should change the parsing to not use the expression head cell1d (lol), then the rest of this will be non-breaking and this can be moved out of 1.0.

[JeffBezanson]

Parser change done.

[mauro3]

I don't know whether it is still on the table to use {} for Tuple{}. But here one argument against it: in where constructs, which already use bare {} it would be confusing to have another set of bare {}.

Tuple{X,Y} where X<:Tuple{T,Y} where {Y,T}
# would become
{X,Y} where X<:{T,Y} where {Y,T}

[oscardssmith]

I would like to +1 {} for sets and dicts. Besides compatibility with python, it goes two very common structures one very convenient syntax

[timholy]

Another option is a lisp-like representation of tuples (as a linked list). There's one coming (called TupleLL) as part of #23692.

[davidanthoff]

Another option is a lisp-like representation of tuples (as a linked list)

Do we expect that to be widely used by a large fraction of the user base? In my mind that should be an important factor in the decision what to do with {},

[timholy]

Unlikely but possible. Currently "lispy-tuple" programming with ordinary tuples is O(N^2) on the compiler, but if we introduced an efficient conversion between ordinary tuples and linked-list tuples then we could make it O(N). If that happened, then they might end up being used relatively widely.

[sighoya]

Another problem with {} as Tuple type is the inclusion of values inside the curly brackets:

Array{Int64,2}

which is maybe a problem for future syntax:

struct A{S,T=S*3} ... end

[StefanKarpinski]

I really think we should let 1.0 come out, settle in and see where there's real syntactic pain. Having some good syntax available to address pain points that emerge is a good thing. It's hard to predict what the real issues will be and which apparent problems evaporate as people work around them.

[timholy]

Agreed, I was definitely not suggesting this for now (that would be crazy), simply planting the seed for some future discussion. Months or years later It's easy to forget these thoughts.

[ajkeller34]

I really think we should let 1.0 come out, settle in and see where there's real syntactic pain.

There's some syntactic pain in conflating indexing by integer offsets and getting keys when both could be considered useful operations on a data structure, for example in AxisArrays but not exclusively there. Curly braces could lower to get (which could be renamed getkey for clarity, because what am I getting exactly?). See #25057 (comment) On second thought, I don't think that's the available curly brace syntax under consideration, but the syntactic pain remains...

[StefanKarpinski]

The is now getproperty which addresses some of that. The only syntax that’s available here is braces not used for indexing.

[RaulDurand]

Sorry for awakening this old topic. I was introducing the language to a C++ programmer and he was not very attracted to the use of begin-end delimiters. I was wondering if, at some point, the use of {} as the block delimiter had been discussed.

[StefanKarpinski]

Lol