Poll: checks on direct assignment?

[Ovid]

@druud @happy-barney @perigrin @rabbiveesh @rwp0 @SysPete @tobyink @demerphq

This is probably the most contentious issue. The attribute poll strongly rejected attributes. The casing poll leaned towards built-in checks being SHOUTY, with title-cased being a second option. To my surprise, no one voted for lower-case built-in checks. We have one last "major" thing to decide on before I can write a spec.

We currently have the following syntax proposed:

my INT $count = 0;
my HASH[STR] @array; # all elements must be hashrefs whose values are strings
my ARRAY[HASH[INT]] %hash; # values must be arrayrefs of hashrefs of integers

In the current spec, if we do $hash{some_key} = \%something, it instantly fails because that is not an arrayref. Same for $hash{some_key} = [1,2,3,4];. However, $hash{some_key}[0] = \@some_array would silently succeed because we didn't assign directly to the variable.

This poses a problem. my ARRAY[HASH[INT]] %hash doesn't guarantee that we have arrayrefs of hashrefs of integers. This is because the check is attached to the variable, not to the potentially deeply nested values. Why?

1. Complex user-defined checks such as array refs of bijective hashes could be very expensive
2. What if something elsewhere alters the complex references and violates our checks?
3. What if something elsewhere defines a check on the complex references and they're not compatible with our checks?

The idea is that for the MVP, we only validate against direct assignments to the variable.

1. It still gains us some benefit
2. It doesn't leave us worse off than before
3. It's much more performant
4. Less likely to have weird "action at a distance"

However, it means that a declared check isn't really a guarantee. No one is happy with the trade-off. What should we do?

As a third option, I thought about re-validating the check across the entire data structure when a variable falls out of scope. We won't necessarily see the error when it happens, but we'll see the error. It's a rubbish compromise, but it seems better than nothing. However, while it seems a reasonable compromise, I can't help but think there are edge cases I haven't considered (that's often the case).

[tobyink]

Some variables never fall out of scope until global cleanup.

[Ovid]

Yes, that's true. This will mostly benefit subroutines. We still have something available to catch these cases, but I don't know that it's enough.

[happy-barney]

This case is what I was writing about earlier - first we should have full set of feature where we want to go and then split it into smaller steps.
And to be honest, this project to me feels like approach I criticized on facebook.

In this particular case I voted for something else - that means do more preparation tasks.

What you actually described is actually completely different problem, imagine:

my ARRAY [ item => ARRAY [ item => INT, min_length => 1, max_length => 2 ] ] $value;
my @foo = (1);

$value->[0] = \@foo;

now:

• pop @foo will break contract of $value
• push @foo, q (broken) will break contract of $value
• $foo[4] = ... will break contract of $value
• imposing contract on @foo may break current code using any of previous

Counterexample to imposing contract:

my ARRAY [ ARRAY [ INT ] ] $int;
my ARRAY [ ARRAY [ STR ] ] $str;
my @foo;

$int[0] = \@foo;
$str[0] = \@foo;

push @foo, q (foo);
push @foo, 1;

[happy-barney]

or another alternative - MVP should provide only:

• declaration syntax - that includes dedicated symbol space, which is imho large enough to do it on its own
• on demand check (ie, predicate on expression)

[rabbiveesh]

Moo has a similar issue, that types applied to attributes only check on direct assignment to the attribute. Points to Sub::HandlesVia that it does respect the type constraint for all the methods it provides.

I think it's surprising behavior to declare some check, and then write code that assumes the check is true, only to find out later that your assumption was simply wrong. It's a false sense of security, and actually a step back (it's kinda like my experience using AI to help write code, it lulls you into a false sense of security + then you push bugs into prod. multiple times)

[perigrin]

(I just discovered this reply with about 1.5 sentences written in a browser tab. I thought I'd already hit "post" days ago sigh)

I voted "something else" but for most practical purposes I'm a "yes".

The something else is add a keyword builtin::assert that allows you to trigger validation, with this you can choose to validate whenever you want. After a call to an eternal library that might have manipulated the data by reference, call builtin::assert($value, CHECK) on it … got some complex data structure where you want the first element of the array stored in the entities array matches a certain type? for my { entities: [$first, @] } (@levels) { builtin::assert($first, PLAYER_CHECK) } … it's the simplest thing that would get us past this and IMO it's something we're going to want later anyway.