Where is that proposal
I just don’t see how we can avoid almost completely duplicating our code bases for cross compilation due to the implicit -> given changes. This is not a minor detail. Yes we can somewhat avoid this with not changing anything and relying on Scala 2 support, but once we want to make the move into the new syntax, we might as well create a whole new branch for our libraries.
I just don’t see how we can avoid almost completely duplicating our code bases for cross compilation due to the
implicit→givenchanges. This is not a minor detail. Yes we can somewhat avoid this with not changing anything and relying on Scala 2 support, but once we want to make the move into the new syntax, we might as well create a whole new branch for our libraries.
implicits are still around, so for cross-building with 3.0 this will not be an issue. The intention is that as long as cross-building is widely needed, the large language subset that is common between 2 and 3 will be maintained.
Then would it be possible to leave the given implicit rework to Scala 3.1 or 3.2?
It seems this would make the switch to Scala 3 and Dotty much less controversial overall, and I think the given redesign still needs more work and experimentation.
The books can always be rewritten when Scala 3.x comes out (for a small value of x) with the new implicits, and can still be called things like “Programming in Scala 3”.
4 Likes
I too think that the new given syntax is not yet quite there.
Every time someone mentions the implicits redesign, five new proposals pop up, addressing some of the issues but introducing others. Which then leads to new proposals, and so on. This needs more time to ripen. I’d rather have it not ready for 3.0 and make sure the design is solid than rushing it and getting it wrong.
It would also make it easier to maintain code that can be compiled with both 2.13 and 3.0
5 Likes
Yes, please let’s leave the implicit redesign out until we come up with something much more unanimous.
I do wish some of the tweaks that were suggested for the existing implicit syntax would have been implemented, though.
1 Like
I believe it’s worth noting that the design of givens has been stable and in widespread use for about a year now. The only thing that changed was what terms to use for the new concepts. The semantics, by contrast has stayed the same over that time. In retrospect, I believe even the very first proposal from October 2018 (witness/with) would have been fine. Not optimal - I think we do have reached some improvements since - but acceptable and clearly better than the status quo. At some point there needs to be an end to discussions and a decision needs to be reached. I believe that point is overdue.
I do follow all comments that are made on the various threads and take them into account. I don’t reply to all of them since I do not want to monopolize the conversation and my days are finite. But if something is really interesting I even go to the length of trying a new proposal in depth by redoing all the doc and spec pages according to it. I did that at several points in the past, most recently a couple of weeks ago when I gave defaults a second chance. After all these experiments my feeling is that the current design is actually really good, and I see that feeling shared by more and more people. I know it will never be unanimous, for that current implicits are too entrenched.
7 Likes
For clarity, please can you send a pointer to the latest documentation. E.g. is it derivation.html or derivation-new.html at https://dotty.epfl.ch/docs/reference, or is it somewhere else.
Thanks,
Rob
It says so at the start of each section, e.g. for derivation.html you’ll see:
Note The syntax described in this section is currently under revision. Here is the new version which will be implemented in Dotty 0.22.
I’m not sure what you mean by “widespread use”. The whole point behind this discussion is to note how most developers migrate slowly, so I would imagine most developers do not even experiment with newly unreleased features, especially when they can only be experimented with an entire new compiler that is (currently) incompatible with most developers’ code.
This is perhaps because most of the previous alternative proposals have been focusing on minor syntactic details rather than addressing the motivation – simplifying implicits – by tackling the semantics. Again, I implore you to take a look at my alternative proposal; it views the semantics of implicits differently than before, aiming at honing the semantics towards the higher-level use cases and design patterns rather than the underlying lower-level abstractions.
1 Like
Again, I implore you to take a look at my alternative proposal;
I have already stated that I have looked in depth at all comments, including your proposal. I don’t think it goes in the right direction for the reasons @ichoran already brought up.
2 Likes
I had hoped you would’ve replied this earlier on the alternative proposal thread, as this thread is probably not the place to discuss this.
However, what’s still relevant to this discussion is how different approaches to the implicits rework have not been attempted, and that the current proposal seems to many of us a step backwards in simplicity, which will greatly make it harder for people to migrate to Scala 3.
Given that the social dynamics on online forums is such that negative opinions are voiced more willingly than positive ones, I guess I’ll take the effort to say that I do actually like 0.21 implicits quite a lot. Had a couple of issues with what I’ve seen in 0.22 that I raised in the “revisiting…” thread.
3 Likes
Oh, and that I’d prefer a single extension method syntax that is as ergonomic as the one with the extension keywod but accomodates for receivers of different types, something along the lines of
given Ctx[A]
extend (theA : A)
def f (otherA : A) = ???
def g (otherA : A) = ???
def [B] h(theB : B) = ???
extend (nested: Ctx[Ctx[A]])
def flatten() = ???
1 Like
but yeah, I think what we have overall is likeable. Not exclusively, other proposals might be nice too, but I find what’s there good. (just to steer my comments back to the intended positiveness 
)
1 Like
They also often suffer from the echo chamber phenomenon, so it’s really hard to say what is the overall opinion. Experimentation is the key here, and we haven’t been experimenting with all the options yet.
That might be the case. My intent was not to argue against your proposal, efforts to table alternative proposals, or you arguing in favour of your proposal. I find all that healthy dynamics, and your work welcome.
On the other hand, I think that this experimentation could only happen if Scala 3 is shipped without the new implicits, as others recently said they would prefer, otherwise it will never be released.
Given that I sufficiently like what we have here, and that in the last year no such experiment materialized except yours, in my opinion (non-autoritative as it is) that would be a price not worth paying. I think your proposal should be properly considered, as it appears to be happening (i.e. people look at it and express their opinions), and then whichever of these 2 directions is chosen, it should land in Scala 3. Opportunistic tweaks are meanwhile welcome to the chosen one.
edit: tl;dr imo extrapolating from past activity there is no point waiting for proposals other than yours and what’s currently in Dotty
2 Likes
Yep, I agree on that 
Both sbt and mill support mixing Java and Scala source files in a single project. Is it possible to allow for mixing Scala 2.13 and Scala 3 source files in a single project since they are binary compatible?
This feature will enable library authors to create cross version libraries that optionally depend on Scala 2 macros. The library users can upgrade most of source files of their application to Scala 3, and leave some of source files in Scala 2, e.g. a file contains some one-liner type class derivation declarations with Scala 2 macro annotations .
@lihaoyi What do you think of the idea as the maintainer of mill?
3 Likes