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

  • Thread starter Thread starter Armin Zingler
  • Start date Start date
A

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
 
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
Click to expand...

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

var x = 17;
 
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.
 
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.
 
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,

I did not study it deeply however
private x

sub bla
x = 17
end sub
Click to expand...
sub ble
x = "Armin"
end sub

What kind of type the compiler has to assign?

Cor
 
Cor Ligthert said:
Armin,

I did not study it deeply however

sub ble
x = "Armin"
end sub

What kind of type the compiler has to assign?
Click to expand...

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 said:
See Kelly's and Tom's latest answers. I don't understand what's so
difficulty with my question.
Click to expand...

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


Armin
 
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
 
Cor Ligthert said:
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.
Click to expand...

ok :-)
However in my idea stays the fact that you cannot declare a global
type without its type
Click to expand...

It is not without a type. The type can be infered from the expression.
and use it twice with two types.
Click to expand...

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
 
Cor Ligthert said:
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).
Click to expand...

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.
 
\\\
In my idea too, however as it is in a method there is known at least
the sequance of processing.
Click to expand...

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.
 
Cor Ligthert said:
In my idea too, however as it is in a method there is known at least
the sequance of processing.
Click to expand...

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
 
Back
Top