Proposal: type deduction in assigments

  • Thread starter Thread starter steve donovan
  • Start date Start date
S

steve donovan

Hi everyone,

I was wondering if anybody had made a proposal for deducing variable
type in assigments. This is in effect exactly what is happening in
"Dim list As new ArrayList()" and a variant of this idea is being
considered for the new C++ standard (as a use for the obsolete 'auto'
keyword)

In effect, the idea is to reduce unnecessary typing. Rather than:

ArrayList list = new ArrayList()

we can say:

let list = new ArrayList() //(or 'dim','var', or whatever)

There is no serious magic involved here; the compiler must work out the
type of the initialization expression anyway, and will use that type
for the new variable 'list'. I've personally implemented for a C++
interpreter and it was not a difficult feature to add.

There are interesting complications when initializing a variable with
an expression, because it could return a derived class which is not
publically available, but I'm sure these issues could be worked out.

steve d.
 
steve donovan said:
Hi everyone,

I was wondering if anybody had made a proposal for deducing variable
type in assigments. This is in effect exactly what is happening in
"Dim list As new ArrayList()" and a variant of this idea is being
considered for the new C++ standard (as a use for the obsolete 'auto'
keyword)

In effect, the idea is to reduce unnecessary typing. Rather than:

ArrayList list = new ArrayList()

we can say:

let list = new ArrayList() //(or 'dim','var', or whatever)
Click to expand...

Anders dicussed this type of feature in a whiteboard talk last year some
time(I think). I think this is the link[1], if not the syntax he was playing
with was basically

var list = new ArrayList();

The syntax makes sense(although dim(ension) and let are not good choices,
IMHO). I personally would lean towards 'implicit' since it is already a
keyword, is not applicable in variable or field declarations (although I am
unsure how well it would work with fields in simple grammars) and while a
bit long, its still less than ArrayList and much less than KeyDownEventArgs
or NotSupportedException or a plethora of other options.

I do think, however, that simple property declarations would cut down on
typing a great deal more than this would(although, hte implicit keyword
could be used there as well...come to think of it)

public implicit string MyProp{get;private set}
or
public implicit string YourProp{get;set}

1.
http://www.microsoft.com/downloads/...73-69F8-4871-B95D-4EBD2806F62F&displaylang=en
 
I'm glad that he's considering this feature. 'var' seems fine to me,
perhaps because of the JScript precedent, although of course it does
mean another keyword. Anything that reduces typing and enhances
readability is a plus.

By 'simple property declarations', you mean a way of easily exporting a
private field as a property?

steve d.
 
steve donovan said:
I'm glad that he's considering this feature. 'var' seems fine to me,
perhaps because of the JScript precedent, although of course it does
mean another keyword. Anything that reduces typing and enhances
readability is a plus.

By 'simple property declarations', you mean a way of easily exporting a
private field as a property?
Click to expand...

More an easy way of creating a property without having to deal with the
backing field, etc, sort of how event properties currently work. Exporting
it as a property would be a bad way of saying it, IMHO.
 
Back
Top