Need for `implicit` keyword on parameters

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Need for `implicit` keyword on parameters

Craig Tataryn
Is there a real need for specifying the `implicit` keyword in front of a parameter?  Couldn't the compiler -- after parameter binding fails to satisfy all values -- then flip to a strategy which finds suitable implicit values for the missing parameters? 

Regards,

Craig

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Need for `implicit` keyword on parameters

Dennis Haupt
so you want to make implicits implicit? too much magic in my opinion

2016-04-26 22:18 GMT+02:00 Craig Tataryn <[hidden email]>:
Is there a real need for specifying the `implicit` keyword in front of a parameter?  Couldn't the compiler -- after parameter binding fails to satisfy all values -- then flip to a strategy which finds suitable implicit values for the missing parameters? 

Regards,

Craig

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Need for `implicit` keyword on parameters

Adriaan Moors-7
In reply to this post by Craig Tataryn
Sure, technically we could do that, but I don't think it would be good language design -- documenting your intent is important. Type inference is great, but you should still provide full type signatures for public members. 

Without the implicit keyword error messages could not be as informative. Did you mean to have these arguments inferred? Did you want eta-expansion? Or should they have been provided explicitly?
The same argument could be made for the abstract keyword: the compiler could simply complain when you instantiate the class instead of when you accidentally define a class that can't be instantiated.

On Tue, Apr 26, 2016 at 1:18 PM, Craig Tataryn <[hidden email]> wrote:
Is there a real need for specifying the `implicit` keyword in front of a parameter?  Couldn't the compiler -- after parameter binding fails to satisfy all values -- then flip to a strategy which finds suitable implicit values for the missing parameters? 

Regards,

Craig

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Need for `implicit` keyword on parameters

Craig Tataryn
In reply to this post by Dennis Haupt
Well if you think about it, we're already doing so for functions. Bury this somewhere in your code:

implicit def toInt(s:String) = s.toInt

Then do this in scope:

val i:Int = "1"

Same level of magic IMHO

Craig



On Tue, Apr 26, 2016 at 1:24 PM -0700, "Dennis Haupt" <[hidden email]> wrote:

so you want to make implicits implicit? too much magic in my opinion

2016-04-26 22:18 GMT+02:00 Craig Tataryn <[hidden email]>:
Is there a real need for specifying the `implicit` keyword in front of a parameter?  Couldn't the compiler -- after parameter binding fails to satisfy all values -- then flip to a strategy which finds suitable implicit values for the missing parameters? 

Regards,

Craig

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Need for `implicit` keyword on parameters

Naftoli Gugenheim

Are you proposing to also leave off the keyword in front of the thing that gets used implicitly? Or just when declaring the parameter that will accept it?


On Tue, Apr 26, 2016, 4:30 PM Craig Tataryn <[hidden email]> wrote:
Well if you think about it, we're already doing so for functions. Bury this somewhere in your code:

implicit def toInt(s:String) = s.toInt

Then do this in scope:

val i:Int = "1"

Same level of magic IMHO

Craig



On Tue, Apr 26, 2016 at 1:24 PM -0700, "Dennis Haupt" <[hidden email]> wrote:

so you want to make implicits implicit? too much magic in my opinion

2016-04-26 22:18 GMT+02:00 Craig Tataryn <[hidden email]>:
Is there a real need for specifying the `implicit` keyword in front of a parameter?  Couldn't the compiler -- after parameter binding fails to satisfy all values -- then flip to a strategy which finds suitable implicit values for the missing parameters? 

Regards,

Craig

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Need for `implicit` keyword on parameters

Craig Tataryn
Just the keyword before parameter. The argument for this keyword placement seems to have to do with being explicit about when we want to make use of implicits. I'm not sure that is necessary though.

Craig


_____________________________
From: Naftoli Gugenheim <[hidden email]>
Sent: Sunday, May 29, 2016 8:48 PM
Subject: Re: [scala-debate] Need for `implicit` keyword on parameters
To: Dennis Haupt <[hidden email]>, Craig Tataryn <[hidden email]>
Cc: scala-debate <[hidden email]>


Are you proposing to also leave off the keyword in front of the thing that gets used implicitly? Or just when declaring the parameter that will accept it?


On Tue, Apr 26, 2016, 4:30 PM Craig Tataryn <[hidden email]> wrote:
Well if you think about it, we're already doing so for functions. Bury this somewhere in your code:

implicit def toInt(s:String) = s.toInt

Then do this in scope:

val i:Int = "1"

Same level of magic IMHO

Craig



On Tue, Apr 26, 2016 at 1:24 PM -0700, "Dennis Haupt" <[hidden email]> wrote:

so you want to make implicits implicit? too much magic in my opinion

2016-04-26 22:18 GMT+02:00 Craig Tataryn <[hidden email]>:
Is there a real need for specifying the `implicit` keyword in front of a parameter?  Couldn't the compiler -- after parameter binding fails to satisfy all values -- then flip to a strategy which finds suitable implicit values for the missing parameters? 

Regards,

Craig

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.