One could. But no-One who could, is.
I think such hair-splitting can actually be somewhat important. In this case, the subtyping direction creates a huge discontinuity from the “theoretic hair splitting” point of view, and I’m baffled as to why that happened. The other direction has zero problems theoretically, and the only problem is that you have to actually specify names. Which is the whole point.
2 Likes
I think one needs to look at it from two view angles.
Names are indeed the important and value adding part on the “processing side”. That’s where you do something with your tuple. There having descriptive names to access the fields is most helpful. Names are also helpful when defining structured data, but it’s not worth yet to commit to a case class.
But at the “input side” of some processing machinery names are often a distraction. Needing to specify the names when supplying literal data to the processing machinery seems superfluous.
Now one can of course try to fix that by applying a call to (a hypothetical, magic) .widen on a “raw” tuple if the expected type is a named tuple. Sometimes you will need to call .widen yourself in this scheme.
This is done in the opposite direction right now, with an auto inserted .toTuple call if the expected type is a “raw” tuple but the supplied one a named one. Sometimes you will need to call .toTuple yourself in this scheme.
The question that matters from the usability perspective is which way this is more of an issue. IDK, as I have very limited real world experience with this feature at all. Like most others, I guess.
That’s why I’ve said maybe a longer testing period is needed. And maybe it would be beneficial to try both approaches, and see how it goes in the field? At least we need some more thoughts experiments which try to uncover when .toTuple or .widen calls would become annoying to write.
But I think having “raw data” in the form of “raw” tuples as inputs will be common (tuples are supposed to handle unstructured or semi-structured input data), and having to lift / widen a “raw” tuple to its named form instead just relying on the sub-typing relation (even it looks “funny”) is the more pragmatic approach.
OTOH I’ve argued not only once in this forum that things should be systematic, and symmetric if possible, as exceptions make a language ugly and unpredictable and because of that hard to learn and memorize.
So as this is quite an important decision I would really call for more experimentation to find a (close to) optimal solution most people can agree on.
How long? Named tuples will be no longer experimental in 3.6, which is already in RC. Or are the conversions mentioned here special in some way in this respect?
Note: I have no interest in named tuples, somehow they do not attract me and I do not plan using them at the moment. I can be concerned about effort spent implementing them, as this effort would be better spent elsewhere in my opinion, but I am not paying the bill, therefore my opinion is not relevant. I would hate if they made other features difficult to implement or maintain, though.
I have also no horse in this race, I’m actually OK with the current proposal as it is (besides one small syntactic quirk). But I do think that named tuples will become a very important feature in the long run.
The point is: Others had serious objections to the current approach, witch should be taken into account I think.
It’s maybe theoretical hair splitting, but theory is important as it’s the ground on which everything stands.
Maybe it makes no difference in practice. But who knows?
The whole feature couldn’t be even tested in its full glory as it’s still not even fully implemented! (Maybe in some nighlies, I didn’t try)
Nobody knows whether automatically inserted .toTuple calls are good enough as there was literally no testing period at all.
That’s why I ask once more: Why this rush? Better taking longer and delivering something (close to) perfect than rushing a potentially problematic solution just to have “something” out.
Once commited it will be hard to change this again so it’s important that the solution is as flawless as possible.
BTW: There is also still the option to not have any sub-typing relation (for now).
In theory conversions in both directions could be based on methods and not on sub-typing. (But no clue what kind of worms could come out of this, as there is again no way to test this).
Named tuples have been fully implemented since 3.5.x under a flag and without a flag under the 3.6.x RC.
1 Like
Do you mean experimental and language imports, or something else?
When I wrote “flag” I meant a language import flag.
Now I’m confused.
You say “named tuples have been fully implemented since 3.5.x” but there is the other thread I linked where someone has an issue with not working automatic .toTuple insertion.
I tried that on Scala 3.5.2 with code taken directly from the documentation and it did not work for me either.
I’ve used -experimental as compiler flag and the named tuple language imports. Did I miss something?
1 Like
They are fully implemented since 3.5. In 3.5 you need to enable them using a compiler option or a language import, in 3.6 they are part of the standard language, enabled by default (and they can bite you in rare situations even when not using them). This is rephrased from original:
Named tuples have been fully implemented since 3.5.x under a flag and without a flag under the 3.6.x RC.
OK, I see I need to ask more directly:
Why does the code from the documentation not work in 3.5.2 despite that feature being “”“fully implemented”“”?
I’ve linked the other thread, which has the not working code example, for a reason… But as obviously nobody tried out the code there here a Scasti:
As a matter of fact, this code—which is from the docs—does not compile.
So, as matter of fact, nobody could have tried out this feature out so far.
It does also not work in 3.6.1:
So what is going on here?
Why does nobody have to say anything about the argumentation in my other comment. This feature was never ready for testing, and now it’s pushed despite having quite some theoretical issue. (Like said, IDK whether this theoretical issue is a practical one, but nobody can know this, as nobody could have tried out…)
Or am I just too stupid to make the code from the docs work?
It turns out we still have to implement the automatic .toTuple insertion. Right now you have to insert it manually.
val x: (String, Int) = Bob.toTuple // works
We’ll do a pull request for an upcoming 3.6 version. Thanks for pointing this out, this was indeed overlooked.
On the other hand, maybe it was a good thing to go step-by-step here. That gives us the chance to validate the conversion with more code that’s already out there to check that it would not break anything.
3 Likes
Let’s please keep it manual for now!
Anyone who wants it automatic can make it so themselves. It’s much harder to remove it.
2 Likes
since we use [] for type parameters and other languages use <> can we flip it around?
val foo = <1,2,3>
and finally an excuse to delete the xml syntax? 
EDIT: this is on the wrong thread
2 Likes
To me it all seems really rushed, the point of having something as experimental is for people to experiment with it to see what works and what doesn’t !
And in this case, there wasn’t really time for it, only 3 of month (to the day)
The SIP proposals are not very vocal about in which versions they become experimental, and in which they become final, so it’s hard to quickly find an average. But this definitely feels below average !
And it feels particularly short given there was no post in this thread indicating it becoming experimental (or even finalized).
The last posts before the current discussion being from the 15 August (so before 1.5.0 was released), and 20 September (a concern which received no reply)
You’ll note this last part is required by the SIP specification:
“At that point, the SIP Manager posts a follow-up comment on the Pre-SIP discussion to invite the community to test the feature and provide feedback.”
https://docs.scala-lang.org/sips/process-specification.html#implementation-stage
Overall I feel it would be best to remove this feature from 1.6 to give people more time to test the ergonomics of this typing direction.
This is a drastic action, but I feel it is the last opportunity we have before possibly making a mistake that would haunt us for a long time.
(See XML literals, left-associative methods (arguably not a mistake, but still a burden), or even implicit conversions)
And is justified on a more judicial side by a failure (although this seems a strong word) to follow the SIP specification
6 Likes
Perhaps guillemets have entered the chat.
1 Like
Implementing something like automatic conversion in haste, just before a RC becomes a final / stable, without any time for discussion or testing? I agree with Sporarum this would be rushed.
If some changes are necessary, the only thing which could be implemented with “due diligence” for 3.6 is delaying making the whole feature final, ie. keeping it still experimental.
1 Like
Named tuples work very well without the implicit conversion. There’s already lots of cool stuff being built on it. The question is whether we want to go ahead and implement the conversion now or later. I think I agree with @Ichoran that it’s better to wait with this for a while and see whether there is really a need for it. So the conversion won’t ship in 3.6. We’ll update the doc page accordingly.
2 Likes
Note that my point is not (only) about the implicit conversion, it was for the feature as a whole !
In particular the issue of the sub-typing direction between named and unnamed tuples.
1 Like
We discussed subtyping at length in the SIP committee. The decision was that the subtyping direction would not be changed. There are very good reasons for the implemented design that have been laid down clearly. Also, an alternative design with a reversed subtyping direction did not exist in either detailed spec or implementation, and nobody stepped forward to put in the effort to produce one. So it was the existing design or nothing.
1 Like