A var keyword to distinguish uninitialized and undefined

[Ovid]

Currently, Perl has no distinction between undefined and uninitialized.

$ perl -MDevel::Peek -E 'my $x; Dump($x)'
SV = NULL(0x0) at 0x12c00d858
  REFCNT = 1
  FLAGS = ()
$ perl -MDevel::Peek -E 'my $x = undef; Dump($x)'
SV = NULL(0x0) at 0x14601c658
  REFCNT = 1
  FLAGS = ()

That causes a problem for runtime data checks. Most languages allow you to declare a variable and later assign a value to it:

int x
x = 3     // good
x = "foo" // boom!

We can't easily do that because my $var :of(INT); has an undefined value thus it blows up.

A var keyword would act like my, but allow us to know if the variable has ever been initialiazed. Once initialized in any way, it can never be uninitialiazed unless you say undef $x (not $x = undef). A builtin::initialiazed could help here.

use builtin 'initialized';
var $x;
say initialized $x ? "yes" : "no"; # no
$x = undef;
say initialized $x ? "yes" : "no"; # yes
undef $x;
say initialized $x ? "yes" : "no"; # no
my $y;
say initialized $y ? "yes" : "no"; # yes (it's initialized to  undef)

That would make it trivial to do this:

var $x :of(INT);   # legal, because the check consults builting::initialized
my $y :of(INT);    # illegal, because $y is always considered unitialized

That would raise questions about how var $x becomes initialized.

var $x; # not initialized
say "X is $x"; # what does this do?

This is out of scope for the data checks MVP, but would it be worth considering later?

[Ovid]

That being said, no warnings 'uninitialized'; becomes problematic. And what about this:

var $x;
my $y = $x + 2;

I think that should be fatal (or at least fatal in a scope where initialization is distinguished), but we're so casual about data, I doubt this will ever fly.

[rabbiveesh]

I think in a perfect world, this example will be a compile time error. If we'd want the notion of uninitialized just to defer a check, then it should compile down to really declaring the variable down wherever it's initially assigned to.

Though I believe that this example shows that for our use case here, the added value is too marginal.

[happy-barney]

what kind of variable will var provide? my ? our ? state ?

[druud]

On 2023-06-02 11:27, Ovid wrote: Currently, Perl has no distinction between undefined and uninitialized. |[...] | That causes a problem for runtime data checks ... because |my $var :of(INT);| has an undefined value thus it blows up.

I see undef as a state, not as a value. Both $x = undef; undef $x; make $x to have the (value-less) undef-state. The consequence of that is that I favor using default (obviously defined) values for non-undef types. The default default then represents EMPTY, being 0 for numbers, q{} for strings, etc. For objects, EMPTY can be a blessed reference to an undef scalar, or to an empty hash or array, etc.

…

-- Ruud

[happy-barney]

endless (in p5p) discussion - value exists but is not defined vs value doesn't exist at all

Here it can be slightly mitigated by introduction of special handling of undef - when you read variable, which has value undef, script will die unless undef is valid value. (instead of currently optional warning)

[druud]

On 2023-06-02 13:21, Branislav Zahradník wrote: endless (in p5p) discussion - value exists but is not defined vs value doesn't exist at all Here it can be slightly mitigated by introduction of special handling of |undef| - when you read variable, which has value |undef|, script will die unless |undef| is valid value. (instead of currently optional warning)

Yeah, so undef is not a value but a state. :) There are many sides to this. For example from perlguts: In perl 5.18 and earlier, AVs use     &PL_sv_undef as a marker for indicating that an array element has not     yet been initialized. Thus, "exists $av[0]" would be true for the above     Perl code, but false for the array generated by the XS code. In perl     5.20, storing &PL_sv_undef will create a read-only element, because the     scalar &PL_sv_undef itself is stored, not a copy.

…

-- Ruud

[happy-barney]

value / state ... boundary is blurry :-)

my $sth = $dbh->prepare;
$sth->execute ($value, undef, undef);

Anyway, extrapolation of undef $c:

• this pattern is just another pattern to break SV cycles
• leads to workflow: how to handle weaken? - it can force undefwhen another variable is destroed

[Ovid]

Closing this for now because it's a distraction.