VB 2008: Option Strict On + Infer On at class level

[Armin Zingler]

Hi,

after dealing with the new possiblities of the current VB version, I again
and still wonder why Option Infer can not be used with Option Strict On
at class level, i.e. when declaring a field:

Dim x = 17

Now I found out that the same line does work within a procedure. Actually I
wanted to ask why, but now I see that it is probably because the line is
realy split into declaration and assignment:

private x

sub new
x = 17
end sub

This partially explains the error message, but shouldn't the compiler still
be clever enough to implicitly declare variable x As Integer? It should be
able to infer the type from the expression just like within a procedure.
That's what Option Infer is all about. The compiler does have all the
information. I don't see the problem.

The only explanation I have is that it internally first splits the source
code line into these two parts (declaration+as sigment) while loosing the
type information. Avoidable, IMO.
Armin

[Tom Shelton]

On 2007-12-11, Armin Zingler <az*******@free net.dewrote:

Hi,

after dealing with the new possiblities of the current VB version, I again
and still wonder why Option Infer can not be used with Option Strict On
at class level, i.e. when declaring a field:

Dim x = 17

Now I found out that the same line does work within a procedure. Actually I
wanted to ask why, but now I see that it is probably because the line is
realy split into declaration and assignment:

private x

sub new
x = 17
end sub

This partially explains the error message, but shouldn't the compiler still
be clever enough to implicitly declare variable x As Integer? It should be
able to infer the type from the expression just like within a procedure.
That's what Option Infer is all about. The compiler does have all the
information. I don't see the problem.

The only explanation I have is that it internally first splits the source
code line into these two parts (declaration+as sigment) while loosing the
type information. Avoidable, IMO.
Armin

Probably why they added the var keword in C#...

var x = 17;

--
Tom Shelton

[Kelly Ethridge]

I don't understand your response. The var keyword is not valid at the
class level.

As for the OP question, there is no way to determine at compile time
what Dim x at the class level should be when it could be initialized
from multiple location within the class.

Public Class Stuff
Dim x

Public Sub New()
x = 17
End Sub

Public Sub New(ByVal s As String)
x = s
End Sub

Public Sub Append(ByVal s As String)
x &= s
End Sub
End Class

Which datatype should the anonymous type be when used in Append? The
compiler can't infer it.
Tom Shelton wrote:

On 2007-12-11, Armin Zingler <az*******@free net.dewrote:

>Hi,

after dealing with the new possiblities of the current VB version, I again
and still wonder why Option Infer can not be used with Option Strict On
at class level, i.e. when declaring a field:

Dim x = 17

Now I found out that the same line does work within a procedure. Actually I
wanted to ask why, but now I see that it is probably because the line is
realy split into declaration and assignment:

private x

sub new
x = 17
end sub

This partially explains the error message, but shouldn't the compiler still
be clever enough to implicitly declare variable x As Integer? It should be
able to infer the type from the expression just like within a procedure.
That's what Option Infer is all about. The compiler does have all the
information. I don't see the problem.

The only explanation I have is that it internally first splits the source
code line into these two parts (declaration+as sigment) while loosing the
type information. Avoidable, IMO.
Armin

Probably why they added the var keword in C#...

var x = 17;

[Armin Zingler]

I don't understand. In your case the assignment is missing, so it can't
work. My case is unambiguous:

Public Class Stuff
dim x= "string"
End Class

What does the compiler prevent from declaring x As String? It complains that
Option Strict requires an As clause. That's true unless Option Infer is On
and also the declaration line contains an assignment. Both preconditions are
met, so I don't see a reason for the error.

In other words, everyone who reads the source code knows how x must be
declared in this case. Are there any doubts? If the compiler does not
recognize the same, it's a flaw.

"Kelly Ethridge" <ke***@kellyeth ridge.comschrie b

I don't understand your response. The var keyword is not valid at
the class level.

As for the OP question, there is no way to determine at compile time
what Dim x at the class level should be when it could be initialized
from multiple location within the class.

Public Class Stuff
Dim x

Public Sub New()
x = 17
End Sub

Public Sub New(ByVal s As String)
x = s
End Sub

Public Sub Append(ByVal s As String)
x &= s
End Sub
End Class

Which datatype should the anonymous type be when used in Append? The
compiler can't infer it.
Tom Shelton wrote:

On 2007-12-11, Armin Zingler <az*******@free net.dewrote:

Hi,
>
after dealing with the new possiblities of the current VB
version, I again and still wonder why Option Infer can not be
used with Option Strict On at class level, i.e. when declaring a
field:
>
Dim x = 17
>
Now I found out that the same line does work within a procedure.
Actually I wanted to ask why, but now I see that it is probably
because the line is realy split into declaration and assignment:
>
private x
>
sub new
x = 17
end sub
>
This partially explains the error message, but shouldn't the
compiler still be clever enough to implicitly declare variable x
As Integer? It should be able to infer the type from the
expression just like within a procedure. That's what Option
Infer is all about. The compiler does have all the information.
I don't see the problem.
>
The only explanation I have is that it internally first splits
the source code line into these two parts
(declaration+as sigment) while loosing the type information.
Avoidable, IMO.
>
>
Armin
>

Probably why they added the var keword in C#...

var x = 17;

[Kelly Ethridge]

Yep, I will agree with that. However, it is stated that only local
variables can be inferred, not fields, unfortunately. As for my example,
it was in response to your second example.

Armin Zingler wrote:

I don't understand. In your case the assignment is missing, so it can't
work. My case is unambiguous:

Public Class Stuff
dim x= "string"
End Class

What does the compiler prevent from declaring x As String? It complains
that
Option Strict requires an As clause. That's true unless Option Infer is On
and also the declaration line contains an assignment. Both preconditions
are
met, so I don't see a reason for the error.

In other words, everyone who reads the source code knows how x must be
declared in this case. Are there any doubts? If the compiler does not
recognize the same, it's a flaw.

"Kelly Ethridge" <ke***@kellyeth ridge.comschrie b

>I don't understand your response. The var keyword is not valid at
the class level.

As for the OP question, there is no way to determine at compile time
what Dim x at the class level should be when it could be initialized
from multiple location within the class.

Public Class Stuff
Dim x

Public Sub New()
x = 17
End Sub

Public Sub New(ByVal s As String)
x = s
End Sub

Public Sub Append(ByVal s As String)
x &= s
End Sub
End Class

Which datatype should the anonymous type be when used in Append? The
compiler can't infer it.
Tom Shelton wrote:

On 2007-12-11, Armin Zingler <az*******@free net.dewrote:
Hi,

after dealing with the new possiblities of the current VB
version, I again and still wonder why Option Infer can not be
used with Option Strict On at class level, i.e. when declaring a
field:

Dim x = 17

Now I found out that the same line does work within a procedure.
Actually I wanted to ask why, but now I see that it is probably
because the line is realy split into declaration and assignment:

private x

sub new
x = 17
end sub

This partially explains the error message, but shouldn't the
compiler still be clever enough to implicitly declare variable x
As Integer? It should be able to infer the type from the
expression just like within a procedure. That's what Option
Infer is all about. The compiler does have all the information.
I don't see the problem.

The only explanation I have is that it internally first splits
the source code line into these two parts
(declaration+as sigment) while loosing the type information.
Avoidable, IMO.
Armin
Probably why they added the var keword in C#...

var x = 17;

[Cor Ligthert[MVP]]

Armin,

I did not study it deeply however

>
private x

sub bla
x = 17
end sub

sub ble
x = "Armin"
end sub

What kind of type the compiler has to assign?

Cor

[Tom Shelton]

On 2007-12-12, Kelly Ethridge <ke***@kellyeth ridge.comwrote:

I don't understand your response. The var keyword is not valid at the
class level.

That's true. I guess I missed that part of the original post. Sorry.

--
Tom Shelton

[Michel Posseth [MCP]]

Hi Armin ,
http://www.danielmoth.com/Blog/2007/...e-in-c-30.html

http://www.danielmoth.com/Blog/2007/...er-in-vb9.html

HTH

Michel
"Armin Zingler" <az*******@free net.deschreef in bericht
news:uO******** ******@TK2MSFTN GP06.phx.gbl...

Hi,

after dealing with the new possiblities of the current VB version, I again
and still wonder why Option Infer can not be used with Option Strict On
at class level, i.e. when declaring a field:

Dim x = 17

Now I found out that the same line does work within a procedure. Actually
I
wanted to ask why, but now I see that it is probably because the line is
realy split into declaration and assignment:

private x

sub new
x = 17
end sub

This partially explains the error message, but shouldn't the compiler
still
be clever enough to implicitly declare variable x As Integer? It should be
able to infer the type from the expression just like within a procedure.
That's what Option Infer is all about. The compiler does have all the
information. I don't see the problem.

The only explanation I have is that it internally first splits the source
code line into these two parts (declaration+as sigment) while loosing the
type information. Avoidable, IMO.
Armin

[Armin Zingler]

"Cor Ligthert[MVP]" <no************ @planet.nlschri eb

Armin,

I did not study it deeply however

private x

sub bla
x = 17
end sub

sub ble
x = "Armin"
end sub

What kind of type the compiler has to assign?

See Kelly's and Tom's latest answers. I don't understand what's so
difficulty with my question. It seems you have changed the quoted code from
"New" to "bla". That's not the same, so please don't quote it this way as if
I had written it. Looking at the code above, I don't expect it to work. My
question was different.

Again, the problem is /not/

private x

sub new
x = 17
end sub

because it was only an attempt to find an explanation why this

Dim x = 17

does not work. It might really be the cause, but in the end, the line
"Dim x = 17" is unambiguous and the compiler was able to infer the type of
x. It is integer, just like with local variables. I do know that this
currently does not work but I don't see any reason, why. There might be
an internal one, as explained above, that I, as a programmer and user of the
compiler should not care about, but there is no logical reason.
Consequently, it is possible to change the compiler in a future version. I
was looking for an exaplanation, why not.
Armin

[Armin Zingler]

"Armin Zingler" <az*******@free net.deschrieb

See Kelly's and Tom's latest answers. I don't understand what's so
difficulty with my question.

To clarify: There's no relation between these two sentences, so please don't
get me wrong! :-)
Armin