arkiuat I'm glad to hear there's a checklist for this though 00:01
I might do better to contribute elsewhere. This particular deal seems a little tricky for my level of experience 00:02
[Coke] Every bit helps. 01:43
03:55 arkiuat left 04:00 arkiuat joined 04:05 arkiuat left 04:10 arkiuat joined 04:21 arkiuat left 04:34 arkiuat joined 04:40 arkiuat left 04:54 arkiuat joined 04:59 arkiuat left 05:12 arkiuat joined 05:18 arkiuat left 05:37 arkiuat joined 05:42 arkiuat left 06:03 arkiuat joined 06:09 arkiuat left 06:36 arkiuat joined 06:41 arkiuat left 07:10 arkiuat joined 07:30 librasteve_ joined 07:42 arkiuat left 07:56 arkiuat joined 08:00 arkiuat left 08:31 arkiuat joined 08:38 arkiuat left 08:39 arkiuat joined 08:44 arkiuat left 09:11 arkiuat joined 09:16 arkiuat left 09:39 librasteve_ left 09:56 arkiuat joined 10:01 arkiuat left 10:30 arkiuat joined
ds7832 m: sub g(Int $i, UInt $j is optional) { ... } 10:31
... gives error: «===SORRY!=== Error while compiling <tmp>␤Can't use unknown trait 'is' -> 'optional' in a parameter declaration.␤at <tmp>:1␤ expecting any of:␤ rw␤ readonly␤ copy␤ required␤ raw␤ leading_do…»
This section mentions that there were an "is optional" trait: docs.raku.org/language/signatures#...e_literals 10:32
But I guess there isn't (anymore?). Could I just remove that part in a PR, or was the trait "is optional" present in previous versions and should be mentioned somehow? 10:34
10:35 arkiuat left 10:37 arkiuat joined 10:46 arkiuat left
Geth doc: schultzdavid++ created pull request #4645:
In signatures.rakudoc, remove mention of nonexistent trait `is optional`
11:04
11:14 arkiuat joined 11:19 arkiuat left 11:42 arkiuat joined 11:48 arkiuat left 11:53 librasteve_ joined
ds7832 In the same section ("docs.raku.org/language/signatures#...iterals"), the "Example with some scalar parameters" is incorrect: The output is always False, never True, whatever the input values. 12:06
I can get it to work by adding "is raw" in the signature to $x and $y, but I'm not sure if that's a good idea. 12:07
The output also becomes as indicated there by replacing =:= with === or eqv, but here too I'm not sure if that overall achieves what is intended there. 12:11
12:17 arkiuat joined 12:22 arkiuat left
ds7832 From the documentation on operators, I now think that === is the correct choice. 12:38
12:43 arkiuat joined 12:48 arkiuat left
ds7832 I've now added corresponding changes to the existing PR on the same section: github.com/Raku/doc/pull/4645 13:14
13:16 arkiuat joined
librasteve_ m: my $sig = :('Þor', Str, Int); say <Þor Hammer 1> ~~ $sig; 13:18
guess camelia does’t listen to this channel - anyway, I get #True on my machine for this (or did you mean a different example?) 13:19
13:21 arkiuat left
ds7832 Yeah, the example that I mean is this in the current version: 13:34
m: my \AnyAt = Any.new; sub b ($x=AnyAt, :$y=AnyAt) { say $x =:= AnyAt; say $y =:= AnyAt }; b 1;
It's said to yield «False␤True␤», but actually gives False False 13:35
uh, more verbatim it goes like this, but same issue:
m: my constant AnyAt = Any.new; sub b ($x=AnyAt, :$y=AnyAt) { say $x =:= AnyAt; say $y =:= AnyAt }; b 1;
Better paragraph link: docs.raku.org/language/signatures#...parameter? 13:37
13:41 arkiuat joined
librasteve_ aha - sorry took me a minute to get my brain in gear - my comment in the PR review 14:00
ds7832 Thanks for reviewing! See reply (can do) 14:03
Geth doc/main: 7e71c5abd4 | schultzdavid++ (committed using GitHub Web editor) | doc/Language/signatures.rakudoc
In signatures.rakudoc, remove mention of nonexistent trait `is optional`, and change `=:=` to `===` (#4645)

  * In signatures.rakudoc, remove mention of nonexistent trait `is optional`
Trying to use the trait "is optional" in a function signature throws error "Can't use unknown trait" (in all of v6.c, v6.d and v6.e.PREVIEW).
  * Update signatures.rakudoc: Change `=:=` to `===` and adapt text
... (8 more lines)
14:16
doc/main: 14724ea612 | (Will Coleda)++ | doc/Language/signatures.rakudoc
fix typo
14:22
doc/main: 331b7973b4 | (Will Coleda)++ | doc/Language/typesystem.rakudoc
Move sentence to correct location

Partial application of PR#4642
schultzdavid++
14:24
[Coke] librasteve_: FYI, you said you merged 4643, but I think you didn't press the button 14:26
I'll let you do it in case this was on the wrong ticket or something.
Geth doc/main: 291d77d789 | schultzdavid++ (committed using GitHub Web editor) | doc/Language/signatures.rakudoc
In signatures.rakudoc, remark that "invocant marker" gets explained in the next section

This is the first time the term "invocant marker" is used in this document, so let readers know that they'll find it explained immediately hereafter.
14:30
doc/main: 96c1086d52 | librasteve++ (committed using GitHub Web editor) | doc/Language/signatures.rakudoc
Merge pull request #4643 from schultzdavid/patch-10

In signatures.rakudoc, remark that "invocant marker" gets explained in the following section
librasteve_ Coke: thanks buddy 14:35
ds7832 Coke: Thanks! 14:43
16:16 arkiuat left 16:19 arkiuat joined 16:24 arkiuat left 16:36 arkiuat joined
ds7832 About the opening section of Signatures.rakudoc: I'm starting to think a good solution is to add, right before the last part with the invocant marker, a new sentence and example about slurpy parameters in signatures. 16:39
16:41 arkiuat left
ds7832 Currently the opening section acts as a very good summary of what entries Signatures can have, and I think it's very good to include slurpees in there too. 16:41
16:50 arkiuat joined 16:54 arkiuat left 17:03 arkiuat joined 17:26 librasteve__ joined, lucs_ joined 17:27 librasteve_ left, lucs left, librasteve__ is now known as librasteve_ 17:47 lucs_ is now known as lucs
Geth doc: schultzdavid++ created pull request #4646:
In signatures.rakudoc, rearrange modify the sections Sub-signatures, Captures, and Long names
20:24
doc/main: c4c4b53a3a | schultzdavid++ (committed using GitHub Web editor) | doc/Language/signatures.rakudoc
In signatures.rakudoc, rearrange and modify the sections Sub-signatures, Captures, and Long names (#4646)

  * In signatures.rakudoc, modify the sections Sub-signatures, Captures and Long names
Move the entire section on Long names down, because Sub-signatures and Captures are very closely related to one another.
In section Sub-signatures, change from using `|` to `\`, since captures with `|` are already the topic of the `Captures` section thereafter, and because `\` gives behavior that's more like that of an actual "compound parameter", e.g. that other parameters can still come behind them. ... (6 more lines)
21:52
22:20 arkiuat left