Shouldn't this trigger a compiler error?

[Dude]

I wasn't taking the default value into account. I thought you meant the variable itself wasn't being defined. Sorry!

[Kukulkan]

I wasn't taking the default value into account. I thought you meant the variable itself wasn't being defined. Sorry!

Both

[mhs]

As you can see, the variable is defined by the compiler as a string:

Code: Select all

EnableExplicit

Procedure test()
  If 1=0
    Protected t.s = "Hallo"
  EndIf
  
  If Defined(t, #PB_Variable) : Debug "Defined" : EndIf
  
  Debug TypeOf(t)
  Debug #PB_String
  
EndProcedure

OpenConsole()
test()
CloseConsole()

However the default value is ignored. I think that's a question of design philosophy of the compiler.

[Shield]

I believe it is not. In such case, the value of t.s would have been "Hallo". But it is empty. Thus, the whole declaration was ignored.

There is a difference between declaration and definition. The declaration is moved to the beginning but of course the definition (= initialization)
must be kept on the same line, otherwise the program wouldn't be the same (for example in case of a function call to get the first value).

Say what? It's not undefined. The "Protected" keyword defines it, just like the manual says.

I didn't say this.

My declaration of t.s contained a default value. This was ignored by the compiler as during the first usage of the variable it was empty. But this is not what I defined using "Protected".

Again, the *declaration* wasn't ignored. It has obviously been declared as mhs showed.
It hasn't been *defined* with your value since that assign statement has never been executed.
-> This is totally to be expected.

[TI-994A]

My declaration of t.s contained a default value. This was ignored by the compiler as during the first usage of the variable it was empty. But this is not what I defined using "Protected".

There appears to be some confusion in terms. Whether or not a variable definition is executed, the PureBasic compiler would still automatically declare it. Only when a variable is defined is it instantiated and assigned any default values.

That's the rule in C anyway.

[Kukulkan]

I just did some tests here to see how PB compares to other compilers:

C#

Code: Select all

using System;			
public class Program
{
	public static void Main()
	{
		int z = 0;
		if (z == 1) {
			String t = "Hallo";
		}
		Console.WriteLine(t);
	}
}

-> Compilation error (line 10, col 21): The name 't' does not exist in the current context

VB.NET

Code: Select all

Imports System	
Public Module Module1
	Public Sub Main()	
		Dim z As Integer = 0
		if z = 1 then
			Dim t as string = "Hallo"
		end if
		Console.WriteLine(t)
	End Sub
End Module

-> Compilation error (line 8, col 0): 't' is not declared. It may be inaccessible due to its protection level.

JS

Code: Select all

var z = 0;
if (z == 1) {
  var t = "Hallo";
}
writeln("Out " + t);

-> the variable t is "undefined"

PHP

Code: Select all

$z = 0;
if ($z == 1) {
  $t = "Hallo";
}
echo $t;

-> Notice: Undefined variable: t in [...][...] on line 5

I still think that PB should trigger, at least, some warning (like PHP does).

[Shield]

This is because C# and VB.NET both have a notion of scopes, so t is only valid within the if block.

JavaScript and PHP report the variable as undefined because they are interpreted languages (or more correct,
they are treated as if they were interpreted), which is why the value is undefined (i.e. not initialized), because
the variable has not been defined before its first use. Both languages have no concept of "EnableExplicit".

Edit: the reason why PHP triggers a warning and PB doesn't is because PB knows that the variable exists,
since it has been declared (and found during compilation). PHP doesn't undergo a traditional compilation process,
so it cannot know that the variable exists, it only knows that it hasn't been initialized.

[TI-994A]

...the reason why PHP triggers a warning and PB doesn't is because PB knows that the variable exists, since it has been declared (and found during compilation).

Essentially, this is what PureBasic does to your code:

Code: Select all

Procedure test()
  Protected t.s
  If 1 = 1
    t = "Hallo"
  EndIf
  PrintN(t)
EndProcedure

It declares the variable but does not initialise it with any default value.

[HanPBF]

Code: Select all

EnableExplicit

Procedure test()
  If Defined(t, #PB_Variable) : Debug "Defined 1" : EndIf
  
  ;debug t ; error if uncommented
  
  If 1=0
    Protected t.s = "Hallo"
  EndIf
 
  If Defined(t, #PB_Variable) : Debug "Defined 2" : EndIf	
 
 	debug t
  Debug TypeOf(t)
  Debug #PB_String
 
EndProcedure

OpenConsole()
test()
CloseConsole()

Defined 1 is not in debug output; so starting with "Protected t" the variable is available.
As there is no local scope and no undefine(t, #PB_Variable) (while the latter in a compiler makes no sense), variables should be declared like in Pascal only at the beginning of a procedure.
If declaration gets out of context then maybe a further splitting of procedure is needed...

[mariosk8s]

The issue is not whether the variable is defined or not, but rather whether it is in the expected state.

The problem with this is that it leads to potentially hard to find runtime bugs.
One could argue that it is the programmers fault. I agree. Programmers do screw things up.

That is why one of the jobs of a compiler is lexical validation followed by translation.
This issue clearly falls under lexical validation.

I realize that PB has limited scope support, that's why this would be a feature request.
It would prevent unnecessary runtime bugs.
After all that is the primary reason for EnableExplicit, isn't it?