Make by-name parameters just sugar syntax rather than actual types

Language Design
22

Since this is available, it’s another option instead of extra sugar on () => T that would make it act like () ?=> T already should. (That is–() ?=> T already conceptually behaves the right way.)

I suppose this is better, except that () ?=> T and () => T are really the same thing under the hood…which is kind of the problem that => T and () => T have right now. it’s less of a problem, I think, since you at least would be able to write () ?=> T explicitly in all contexts (if you allowed it to be written in any context), solving one of the main frustrations with => T.

So if it goes this way, at least () ?=> T should have its relationship to () => T made crystal clear.

(I don’t really accept that you have to add () all over the place if we admit that => T is just syntactic sugar for () => T; we just say that when you call it => T you get more sugar which includes automatic insertion of ().)

23

There may be an unintended side-effect that overriding given () would allow invisible behavior injection at point of use.

def when(b: Boolean)(f: => Unit): Unit = {
  given () = { launchMissiles(); () }
  if (b) f else println("That's all, folks!")
}
25

I did not advocate that overriding given () should be possible. That was @LPTK. I think it’s better not to introduce “magical” behavior of this sort.

4 Likes
26

I may have misunderstood the syntax, does a () ?=> Unit mean a context function with a singleton unit value (().type) context? Or does it mean an empty context?
Overriding isn’t possible in the second case, but I’ve read the syntax as the first case.

2 Likes
27

() ?=> Unit would mean no parameters, analogous to () => Unit. If you want a singleton type you’d write Unit ?=> Unit.

6 Likes
29

I can never understand your jokes even with context.

4 Likes
31

You have managed to pack an impressive number of multiple meanings in an impressive number of different places (words, phrases, inferences, etc.).

At some point, meaning found in humor shall be wholly unconstrained, and yet we shall need to summon this infinity of meaning somehow. Fortunately, we Scala programmers already know how to do this.

_

2 Likes
33

I think DummyImplicit ?=> T would work for that already, but it feels like a hack. Having () ?=> T in the language itself would be very nice.