|
00:44
gfldex left,
swaggboi left
00:50
gfldex joined,
swaggboi joined
01:55
arkiuat left
02:08
arkiuat joined
02:13
arkiuat left
02:25
arkiuat joined
02:29
arkiuat left
02:34
arkiuat joined
03:08
ntv left
03:10
apogee_ntv joined
04:20
stanrifkin joined
04:22
stanrifkin_ left
04:54
arkiuat left
04:59
arkiuat joined
05:05
arkiuat left
05:18
arkiuat joined
05:54
arkiuat left
06:07
arkiuat joined
06:12
arkiuat left
06:36
arkiuat joined
06:41
arkiuat left
07:10
arkiuat joined
07:15
arkiuat left
07:37
arkiuat joined
07:42
arkiuat left
08:10
arkiuat joined
08:16
arkiuat left
08:27
arkiuat joined
08:31
arkiuat left
09:11
arkiuat joined
09:17
arkiuat left,
habere-et-disper joined
|
|||
| habere-et-disper | m: `sub foo ( --> 42 ) { return 27 }` | 09:20 | |
| camelia | ===SORRY!=== Error while compiling <tmp> Bogus statement at <tmp>:1 ------> <BOL><HERE>`sub foo ( --> 42 ) { return 27 }` expecting any of: prefix statement list term |
||
| habere-et-disper | m: sub foo ( --> 42 ) { return 27 } | ||
| camelia | ===SORRY!=== Error while compiling <tmp> No return arguments allowed when return value 42 is already specified in the signature at <tmp>:1 ------> sub foo ( --> 42 ) { return 27 <HERE>} |
||
| habere-et-disper | m: sub foo ( --> 42 ) { 27.return }; say foo; | ||
| camelia | 27 | ||
| habere-et-disper | Is this the expected behaviour? I was imagining it would catch the `27.return` and complain as well, no? | 09:21 | |
|
09:38
habere-et-disper left
09:39
arkiuat joined
09:44
arkiuat left
09:49
arkiuat joined
09:55
arkiuat left
09:58
habere-et-disper joined
09:59
habere-et-disper left
10:00
librasteve_ joined
10:08
arkiuat joined
|
|||
| librasteve | habere-et-disper: the docs state If the type constraint is a constant expression, it is used as the return value of the routine. Any return statement in that routine has to be argumentless. docs.raku.org/language/signatures#...row:_--%3E | 10:12 | |
|
10:13
arkiuat left
10:16
stanrifkin left
|
|||
| this is the first I have seen a method variant of return ... it seems to me that (i) we need to either document the method form of return and make the compiler check this or (ii) decide that there is no such thing as a method variant of return and make the compiler reject it ... please can you make a Raku problem solving issue and maybe check if there are any ROAST tests for this? | 10:17 | ||
|
10:25
arkiuat joined
10:30
arkiuat left
10:48
habere-et-disper joined
10:56
arkiuat joined
11:06
arkiuat left
11:11
habere-et-disper left
11:35
arkiuat joined
11:44
habere-et-disper joined
11:45
arkiuat left
11:53
arkiuat joined
12:00
arkiuat left
12:17
arkiuat joined
12:36
arkiuat left
12:47
habere-et-disper left
12:59
arkiuat joined
13:10
arkiuat left,
stanrifkin joined
13:18
arkiuat joined
13:21
ds7832 joined
13:54
Guest551 joined
14:57
librasteve_ left
15:27
arkiuat left
15:35
Guest551 left
15:45
arkiuat joined
16:05
habere-et-disper joined
|
|||
| habere-et-disper | Will do. Checking roast now. I use method chains a lot, so `.return` didn't seem unnatural. | 16:18 | |
| github.com/rakudo/rakudo/issues/6003 | 16:41 | ||
| librasteve | =b | 16:56 | |
|
17:01
habere-et-disper left
18:06
stanrifkin left
18:15
stanrifkin joined
19:34
arkiuat left
19:46
arkiuat joined
19:51
arkiuat left
19:57
Guest551 joined
20:16
ds7832 left
20:18
arkiuat joined,
Guest551 left
20:44
ds7832 joined
23:51
habere-et-disper joined
|
|||