DIM - AS - VARIABLE TYPE likely bug

[bplus]

Hi bartok .. thanks very much for asking this question. I do understand you are feeling somewhat under attack personally and I completely see where you did get a satisfying answer to your query but the subject took on a life of it's own after that point. Your question has highlighted some of the issues I have will my approach to variable names and types. I dim everything and and often get tripped up with string variables. If, at the beginning of my code I have something like Dim Shared  A AS String, days later and multiple lines later I'll run into a situation where I have 

Print B
Print C
Print A
Print D

And I'll forget that A is printing a string value because it looks like it's the same type as the others.

Where strings are concerned I'm now in the habit of A$ as it pops out

Print B
Print C
Print A$
Print D

 Hope you may see the comments here as addressing the issue "DIM - AS - VARIABLE TYPE likely bug" and not bartok personally.

+1 @Dimster, we are all learning here, we all can benefit by information shared by members, @bartok don't get angry please if what's being said is not useful eh, water off a ducks back... Got to say I learned something i did not know from this discussion, thanks for your questions and comments and this whole discussion.

[Kernelpanic]

The whole thing is becoming more and more like a “dispute over the emperor’s beard” (Streit um des Kaisers Bart) or “That's just splitting hairs.”.   

[Dimster]

I'm likely taking this topic a little more off the issue but rather than starting a new thread hoping it's ok to ask it here ... Is there an order to the assignment of a Type for a variable?
For example
Dim A$
Dim A
Dim A!

In the order above, why would not QB64, upon finding the 2nd Dim statement, simply change the type of A from a string to a single. Similar to a redim. So that in this dim order example the last Dim statement for A (A!) would rule? 

I haven't tested this yet but from past coding, this does appear to be the case (ie a 2nd incident of a change in Variable Type but no change in the Variable name) if Dimming locally rather than globally. I think I have in the past had a Dim A$ in one sub and DIM A in another sub without an error message.

Steve's earlier comment about the 2nd encounter of the same Variable Name triggering the error message of Name already in use must only apply to Globally Named variables correct?

[bplus]

I'm likely taking this topic a little more off the issue but rather than starting a new thread hoping it's ok to ask it here ... Is there an order to the assignment of a Type for a variable?
For example
Dim A$
Dim A
Dim A!

In the order above, why would not QB64, upon finding the 2nd Dim statement, simply change the type of A from a string to a single. Similar to a redim. So that in this dim order example the last Dim statement for A (A!) would rule? 

I haven't tested this yet but from past coding, this does appear to be the case (ie a 2nd incident of a change in Variable Type but no change in the Variable name) if Dimming locally rather than globally. I think I have in the past had a Dim A$ in one sub and DIM A in another sub without an error message.

Steve's earlier comment about the 2nd encounter of the same Variable Name triggering the error message of Name already in use must only apply to Globally Named variables correct?

yeah tested you will be enlightened to know a! is already used,

global = shared or constant i say yeah, before i tested ;-))

[Kernelpanic]

There is only one thing that comes to mind regarding this thread (Where are the chips?):

[SMcNeill]

I'm likely taking this topic a little more off the issue but rather than starting a new thread hoping it's ok to ask it here ... Is there an order to the assignment of a Type for a variable?
For example
Dim A$
Dim A
Dim A!

In the order above, why would not QB64, upon finding the 2nd Dim statement, simply change the type of A from a string to a single. Similar to a redim. So that in this dim order example the last Dim statement for A (A!) would rule? 

I haven't tested this yet but from past coding, this does appear to be the case (ie a 2nd incident of a change in Variable Type but no change in the Variable name) if Dimming locally rather than globally. I think I have in the past had a Dim A$ in one sub and DIM A in another sub without an error message.

Steve's earlier comment about the 2nd encounter of the same Variable Name triggering the error message of Name already in use must only apply to Globally Named variables correct?

It applies to variables in the same NAMESPACE.

Code: (Select All)

Dim a As Double



Sub foo

    Dim a As Long

    'dim a as single

End Sub

Take the above example, as an example. 

Written as is, it causes no errors with the IDE, nor any problems with compiling and running (and doing nothing as the code does nothing).  

However, if you unremark that 'dim a as single, it suddenly tosses an error on you!!

Why??

You're trying to dimension a variable with the same name, in the same scope/namespace!

That first Dim a As Double, applies only in the main module.  It's not DIM SHARED, so it's not a global variable.  The scope is limited.  The second Dim a As LOng, is inside the SUB foo -- it's a variable only local for the SUB and not in scope anywhere else.   Having it be the same name, but a different type than the original a, isn't a problem.

That dim a as single, however, now has two variables named "a" being defined in the same scope -- both as local variables in SUB foo.  THIS IS NOT ALLOWED!!  ERROR!! ERROR!! THE IDE IS REVOKING YOUR COMPILING PRIVILEDGES!!

---

So it's a rule of "Can't define the same variable-without-a-suffix as a type more than once, *while in the same namespace/scope range*." 

---

As for your explicit example of: 

Code: (Select All)

Dim A$
Dim A
Dim A!

In this case,  it all depends of what your DEFAULT VARIABLE TYPE is.   IF the default type is single, then DIM A would define A as SINGLE, and then the A! would frown upon you calling its name two in DIM statements.  IF the default type was anything else -- such as DEFLNG A-Z would make the default type LONG, then DIM A would solidify its type AS LONG, and then there'd be no problem with Dim A! as that'd be explicitly declaring A-as-SINGLE variable.