Why do defaults on slurpies throw?

[zoffixznet]

An optional % or @ sigiled param defaults to an empty list. You can also give it a default value:

<Zoffix__> m: m: -> @a? { dd @a }()
<camelia> rakudo-moar 266af373d: OUTPUT: «Array element = []␤»
<Zoffix__> m: m: -> @a = <default list> { dd @a }()
<camelia> rakudo-moar 266af373d: OUTPUT: «("default", "list")␤»

And while a slurpy param also defaults to an empty list, you cannot give it a default value:

<Zoffix__> m: m: -> *@a { dd @a }()
<camelia> rakudo-moar 266af373d: OUTPUT: «Array element = []␤»
<Zoffix__> m: m: -> *@a = <default list> { dd @a }()
<camelia> rakudo-moar 266af373d: OUTPUT: «===SORRY!=== Error while compiling <tmp>␤Cannot put default on slurpy parameter @a␤at <tmp>:1␤------> m: -> *@a = <default list>⏏ { dd @a }()␤    expecting any of:␤        constraint␤        infix stopper␤»

What's the reason for this limitation? It looks to be fairly useful when you want both the flattening of slurpies and some default values to work with.

---

There was propspec codifying this behaviour in 6.d and I moved it to APPENDIXES at least for now: Raku/roast@f7d9be8ad9

[lizmat]

I think the original reasoning is very simple: having *no* values for a slurpy is perfectly valid. One could re-consider that.

…

On 28 Oct 2018, at 22:22, Zoffix Znet ***@***.***> wrote: An optional % or @ sigiled param defaults to an empty list. You can also give it a default value: <Zoffix__> m: m: -> @A? { dd @A }() <camelia> rakudo-moar 266af373d: OUTPUT: «Array element = []␤» <Zoffix__> m: m: -> @A = <default list> { dd @A }() <camelia> rakudo-moar 266af373d: OUTPUT: «("default", "list")␤» And while a slurpy param also defaults to an empty list, you cannot give it a default value: <Zoffix__> m: m: -> ***@***.*** { dd @A }() <camelia> rakudo-moar 266af373d: OUTPUT: «Array element = []␤» <Zoffix__> m: m: -> ***@***.*** = <default list> { dd @A }() <camelia> rakudo-moar 266af373d: OUTPUT: «===SORRY!=== Error while compiling <tmp>␤Cannot put default on slurpy parameter @A␤at <tmp>:1␤------> m: -> ***@***.*** = <default list>⏏ { dd @A }()␤ expecting any of:␤ constraint␤ infix stopper␤» What's the reason for this limitation? It looks to be fairly useful when you want both the flattening of slurpies and some default values to work with. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[zoffixznet]

I think the original reasoning is very simple: having no values for a slurpy is perfectly valid.

Having no values for an optional @-/%- sigilled param is also valid, and you can have a default too

[vendethiel]

I think it's because a slurpy is never "not given". A param, $@% can simply be not passed, but a slurpy will always be "passed".

[zoffixznet]

but a slurpy will always be "passed".

Not really, I'm not "passing" anything. The callsite to a routine with optional @-param looks the same as the one with a slurpy.

• Some arguments may be used to fill an optional @- parameter
• Some arguments may be used to fill a slurpy @- parameter

Parallels with

• No arguments to fill an optional @- parameter are given, use default
• No arguments to fill a slurpy @- parameter are given, use default

There's no ambiguity to the decision of when a slurpy should be given its default value, other than possible implementation detail in rakudo.

On language-level, the decision to block slurpy defaults make no sense to me.

[vendethiel]

No arguments for a positional (with no default) is invalid.
No arguments for a slurpy is totally valid.

[zoffixznet]

No arguments for a positional (with no default) is invalid.
No arguments for a slurpy is totally valid.

So what?

[zoffixznet]

So what?

As in, I don't see the relevance of mandatory parameters to slurpies. You'll still have a total valid slurpy with no arguments if defaults are allowed. In fact, the current behaviour can be explained with a paragidm where a slurpy always has a default value: an empty Array/List.

And the current propspec says that default value must not be configurable by the user, to which I ask: "why?"

[2colours]

@zoffixznet for what it's worth, I think the counterargument could be put in a different light the following way: what can one do to make the slurpy an empty list, if no values were to trigger the default value, rather than the empty list?

And this is where things start to escalate quickly... a missing value is reflected with an empty array for an optional @var parameter as well (named or positional) - however, they don't use the empty array (or even Empty, for that matter) to indicate the absence of a value. The concepts are distinct.

I'm not sure if the same distinction could be preserved(/achieved in the first place) in any way for a slurpy.