-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
what should we use { }
for?
#8470
Comments
I think this would be a great change. More consistency with |
👍 |
I like it a lot
All seem pretty human-parseable. The |
Two other things from today's discussion:
|
I like this. If we make this change and also change |
👍 to that, too. |
@jiahao I think |
However, I think there's many legitimate uses contending for the braces. An alternative would be to use +1 for |
I think I finally stopped typing |
+1 for Tuple{Int, String} and Union{} for being explicit and obviously describing types. |
I think we could implement |
LOL. @jiahao, @simonster – there is a free monoid of fixed points with I'd be ok with this change, although it does really feel a bit wasteful. The idea of making |
I know what you mean. We do need at least |
Closed by #10380 |
I still hold out hope that this will be the final syntax. |
I agree. I'm 100% in favor of this. I'm tired of typing "Tuple", and hopefully soon everybody else will be too. |
Based on the deprecation policy, we should really leave |
In that case, we might want to continue allowing tuples of types in various places. Writing |
Can't you do that just by writing methods that convert tuples to tuple types? |
For 1.0, we should change the parsing to not use the expression head |
Parser change done. |
I don't know whether it is still on the table to use Tuple{X,Y} where X<:Tuple{T,Y} where {Y,T}
# would become
{X,Y} where X<:{T,Y} where {Y,T} |
I would like to +1 {} for sets and dicts. Besides compatibility with python, it goes two very common structures one very convenient syntax |
Another option is a lisp-like representation of tuples (as a linked list). There's one coming (called |
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 |
Unlikely but possible. Currently "lispy-tuple" programming with ordinary tuples is |
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 |
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. |
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. |
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. |
The is now getproperty which addresses some of that. The only syntax that’s available here is braces not used for indexing. |
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. |
Lol |
@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 aComplex128
), 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 withAny[ ]
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.The text was updated successfully, but these errors were encountered: