Add: Signature/Attribute Defaults Based on Definedness

v6d.pod

@@ -9,7 +9,7 @@ Plans for Perl 6 version 6.d
     Created: 09 Aug 2016
 
     Last Modified: 09 Aug 2016
-    Version: 1
+    Version: 2
 
 This documents contains planned changes for v6.d, and who wants to do them.
 
@@ -70,4 +70,61 @@ Examples of this happening have showed up in the past.
 
 Jonathan Worthington
 
+
+=head1 Signature/Attribute Defaults Based on Definedness
+
+=head2 Current Behaviour
+
+Consider the following two examples:
+
+    helper "foo";
+
+    sub helper ($str, :$where) { debug-print $str.uc, :$where; }
+    sub debug-print ($str, :$where = 'out') { ... }
+
+    ########
+
+    class Foo {
+        has $.x = 42;
+        submethod BUILD (:$!x) {}
+    }
+
+If we don't specify a C<:where> argument when calling C<helper> or the
+C<:x> argument when initializing class C<Foo>, the specified defaults won't
+be applied, despite the values not being there, from the programmer's point of
+view.
+
+This means all of the attribute defaults have to be moved to the C<BUILD>
+submethod and the solution for routines is to do (or to work with Captures,
+which hides the passed arguments):
+
+    sub debug-print ($str, :$where is copy ) {
+        $where //= 'out';
+        ...
+    }
+
+=head2 New Behaviour
+
+I propose we add another syntax for assigning defaults:
+
+    sub (:$where //= 'out') { ... }
+    ...
+    has $.x //= 42;
+
+Such defaults would be assigned if the given value is a C<:U> value, even if
+it was explicitly specified.
+
+=head2 Rationale
+
+Currently, the defaults are applied only when the value was not specified.
+This creates issues when we want to just propagate the arguments we received,
+since the mechanism for defaults assumes we gave a value, even though
+it's undefined. The additional method to specify defaults will behave closer
+to what typical (IMO) defaults require: e.g. C<Int:U> is not a useful value for
+a variable that defaults to C<42>.
+
+=head2 Stakeholder
+
+Zoffix Znet
+
 =cut