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+assigment) while loosing the
type information. Avoidable, IMO.
Armin

[Tom Shelton]

On 2007-12-11, Armin Zingler <az*******@freenet.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+assigment) 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*******@freenet.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+assigment) 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***@kellyethridge.comschrieb

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*******@freenet.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+assigment) 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***@kellyethridge.comschrieb

>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*******@freenet.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+assigment) 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***@kellyethridge.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*******@freenet.deschreef in bericht
news:uO**************@TK2MSFTNGP06.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+assigment) while loosing the
type information. Avoidable, IMO.
Armin

[Armin Zingler]

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

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*******@freenet.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

[Cor Ligthert[MVP]]

Armin,

When I had written the reply, I was me not aware that I had changed it and
therefore should have removed the quoting.

Sorry for that.

However in my idea stays the fact that you cannot declare a global type
without its type and use it twice with two types. I don't see what the
compiler can do in that situation (maybe give a signal as it is two times
used with a different type, but that seems to me real gambling because what
is meant). That it is in the constructor can be an argument, however it is
clearer for me to avoid this to get no misunderstandings.

I probably don't have to say that I always write that the IDE/compiler
should do as much logic as there is to prevent messages like we see in C#
"This is a method however declared as property" (This is not the actual text
I am just writing this here in the message).

Cor

[Armin Zingler]

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

Armin,

When I had written the reply, I was me not aware that I had changed
it and therefore should have removed the quoting.

Sorry for that.

ok :-)

However in my idea stays the fact that you cannot declare a global
type without its type

It is not without a type. The type can be infered from the expression.

and use it twice with two types.

It is not used with two types. It has exactly one type and only one type is
assigned.

This should work:

class bla
Dim x = 17

sub test
x = 23
end sub
end class
I do NOT expect this to work:

class bla
Dim x = 17

sub test
x = "whatever"
end sub
end class
Anyways, I don't see any /logical/ reason why type inference is limited to
local variables.
Armin

[Herfried K. Wagner [MVP]]

"Cor Ligthert[MVP]" <no************@planet.nlschrieb:

However in my idea stays the fact that you cannot declare a global type
without its type and use it twice with two types. I don't see what the
compiler can do in that situation (maybe give a signal as it is two times
used with a different type, but that seems to me real gambling because
what is meant).

Well, then you'd have to ask what the compiler should do in the snippet
below too:

\\\
Dim i = 10
i = "Hello World"
///

IMO, in both cases the variable should be typed in the type of the
expression on the right-hand side of 'Dim' + initialization statement.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Cor Ligthert [MVP]]

\\\

Dim i = 10
i = "Hello World"
///

In my idea too, however as it is in a method there is known at least the
sequance of processing.

Cor

[Rory Becker]

>\\\

>Dim i = 10
i = "Hello World"
///

In my idea too, however as it is in a method there is known at least
the sequance of processing.

Isn't that true for fields also? If you debug into a class, you hit the initialisation
of fields (for preinitialised fields) before the constructor.
I'm not sure if the sequence matters for compile time though.

A field needs to be allocated before it can be assigned, but you need to
find an assignment (for an inferred field) before you can determine it's
type.

An initialised field has a value in it's declaration which can be used to
figure the type. To my mind, this is easy and should have been done.

An uninitialised field might need to search the entire class to locate an
assignment before this judgement could be made.
A public unassigned field would need to search the entire project for such
an assignment, and you might not find anything having done that.

At this point you'd produce a compiler error.

--
Rory

[Armin Zingler]

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

\\\
Dim i = 10
i = "Hello World"
///

In my idea too, however as it is in a method there is known at least
the sequance of processing.

But does this matter? That's something about runtime. But we are talking
about compile time. Just like you can look at the source code and see that i
is to be declared as an Integer here, the compiler should be able to see the
same. It does not matter at all when the assignment is done at runtime.
Armin