Options and [SLS 4.2 - var x: T = _]

I know there have been discussions on using Options to avoid null altogether (with proper underlying compiler oprimisations) and I will not go into another debate of the kind right here.
I was just wondering if changing the semantics of default initial values for Options, so that
var x: Option[T] = _
means
var x: Option[T] = None
instead of
var x: Option[T] = null
might be something to go for. 


Thoughts?
Christos
--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

Re: Options and [SLS 4.2 - var x: T = _]

Christos,

-1

I think many have voiced that "_" means too many things. Adding this rule would just add another exception to remember among the other meanings. I personally like initializing by explicit value is better than using "_".

zemian

On Sat, Dec 20, 2008 at 10:00 AM, Christos KK Loverdos <loverdos [at] gmail [dot] com> wrote:
I know there have been discussions on using Options to avoid null altogether (with proper underlying compiler oprimisations) and I will not go into another debate of the kind right here.
I was just wondering if changing the semantics of default initial values for Options, so that
var x: Option[T] = _
means
var x: Option[T] = None
instead of
var x: Option[T] = null
might be something to go for. 


Thoughts?
Christos
--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com



--
http://www.jroller.com/thebugslayer

Re: Options and [SLS 4.2 - var x: T = _]

But wouldn't it be useful if compiler looked for implicit converson like below before assuming the somethings default value ("_") is null?

implicit def nullValue(n: Nothing): AClassName = {  // ... }
Szymon

On Sat, Dec 20, 2008 at 5:04 PM, Zemian Deng <thebugslayer [at] gmail [dot] com> wrote:
Christos,

-1

I think many have voiced that "_" means too many things. Adding this rule would just add another exception to remember among the other meanings. I personally like initializing by explicit value is better than using "_".

zemian

On Sat, Dec 20, 2008 at 10:00 AM, Christos KK Loverdos <loverdos [at] gmail [dot] com> wrote:
I know there have been discussions on using Options to avoid null altogether (with proper underlying compiler oprimisations) and I will not go into another debate of the kind right here.
I was just wondering if changing the semantics of default initial values for Options, so that
var x: Option[T] = _
means
var x: Option[T] = None
instead of
var x: Option[T] = null
might be something to go for. 


Thoughts?
Christos
--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com



--
http://www.jroller.com/thebugslayer


Re: Options and [SLS 4.2 - var x: T = _]

What about a method Predef.default[T].... which returns the default value for T?
So you could write var x: Option[Blah] = default

(In which case x would be assigned 'None'.)
I tend to agree that '_' is overloaded plenty already in Scala, and none of its current meanings really have much to do with the concept of 'default'. It's generally used to mean 'something goes here', where the 'something' is variable. Whereas the value returned by 'default' doesn't change.
As an aside, we'd probably want a safe way to ask if a type /has/ a default, so something like
def optionalDefault[T]: Option[T] = if (T has a default value) Some(default[T]) else None



On 20 Dec 2008, at 19:27, Szymon Jachim wrote:
But wouldn't it be useful if compiler looked for implicit converson like below before assuming the somethings default value ("_") is null?

implicit def nullValue(n: Nothing): AClassName = {  // ... }
Szymon

On Sat, Dec 20, 2008 at 5:04 PM, Zemian Deng <thebugslayer [at] gmail [dot] com> wrote:
Christos,

-1

I think many have voiced that "_" means too many things. Adding this rule would just add another exception to remember among the other meanings. I personally like initializing by explicit value is better than using "_".

zemian

On Sat, Dec 20, 2008 at 10:00 AM, Christos KK Loverdos <loverdos [at] gmail [dot] com> wrote:
I know there have been discussions on using Options to avoid null altogether (with proper underlying compiler oprimisations) and I will not go into another debate of the kind right here.
I was just wondering if changing the semantics of default initial values for Options, so that
var x: Option[T] = _
means
var x: Option[T] = None
instead of
var x: Option[T] = null
might be something to go for. 


Thoughts?
Christos
--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com



--
http://www.jroller.com/thebugslayer



Re: Options and [SLS 4.2 - var x: T = _]

You can implement "default" yourself. I see no reason why this should go in Predef.

--j

On Sat, Dec 20, 2008 at 1:39 PM, Andrew Forrest <andrew [at] dysphoria [dot] net> wrote:
What about a method Predef.default[T].... which returns the default value for T?
So you could write var x: Option[Blah] = default

(In which case x would be assigned 'None'.)
I tend to agree that '_' is overloaded plenty already in Scala, and none of its current meanings really have much to do with the concept of 'default'. It's generally used to mean 'something goes here', where the 'something' is variable. Whereas the value returned by 'default' doesn't change.
As an aside, we'd probably want a safe way to ask if a type /has/ a default, so something like
def optionalDefault[T]: Option[T] = if (T has a default value) Some(default[T]) else None



On 20 Dec 2008, at 19:27, Szymon Jachim wrote:
But wouldn't it be useful if compiler looked for implicit converson like below before assuming the somethings default value ("_") is null?

implicit def nullValue(n: Nothing): AClassName = {  // ... }
Szymon

On Sat, Dec 20, 2008 at 5:04 PM, Zemian Deng <thebugslayer [at] gmail [dot] com> wrote:
Christos,

-1

I think many have voiced that "_" means too many things. Adding this rule would just add another exception to remember among the other meanings. I personally like initializing by explicit value is better than using "_".

zemian

On Sat, Dec 20, 2008 at 10:00 AM, Christos KK Loverdos <loverdos [at] gmail [dot] com> wrote:
I know there have been discussions on using Options to avoid null altogether (with proper underlying compiler oprimisations) and I will not go into another debate of the kind right here.
I was just wondering if changing the semantics of default initial values for Options, so that
var x: Option[T] = _
means
var x: Option[T] = None
instead of
var x: Option[T] = null
might be something to go for. 


Thoughts?
Christos
--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com



--
http://www.jroller.com/thebugslayer




Copyright © 2013 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland