🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 6 September 2022.
hankache Hello #raku 12:32
Is there a way in a function signature to specify the exact type needed without allowing accepting subclasses. i.e I want my argument to be exactly a Cool and I don't want to accept Num or Str. 12:38
antononcube 🤔 12:44
hankache I have been trying to figure this out for a while and can think of anything 12:50
can't*
antononcube Something like this seems to work: sub my-function(Cool:D \arg where { .WHAT === Cool }) { # Your function code here } 12:53
Well, at least &my-function(3) fails because of constraint type check. 12:54
hankache thanks 13:11
guifa I'd maybe even do Mu 14:25
err Mu:D where .WHAT === YourClass 14:26
I'm assuming a Mu parameter can ignore a type check, with the one you have antonon there's a double type check for Cool
but I might be overthinking it
ab5tract guifa: I understood it as Cool just being an example, with the underlying question being "how can I constrain a parameter to meet only a single type, without also matching subclasses of that type" 14:30
librasteve ha - I find raku cool because you CAN do most everything you want - BUT I wonder if it is a GOOD thing to accept a class but not a subclass. I do not pretend to tell you how to write your code, but if it was me, I would be thinking WHY do I want this and maybe try controlling this via a role 14:39
m: subset Foo of Cool where not * ~~ Int | Str; sub fn(Foo \x) { say x }; fn (Cool); fn 42; 14:54
evalable6 (exit code 1) (Cool)
Constraint type check failed in binding to parameter 'x'; expected Foo but got Int (42)
in sub fn at /tmp/cs3EDRcoDI line 1
in block <unit> at /tmp/cs3EDRcoDI line 1
Raku eval (Cool) Exit code: 1 Constraint type check failed in binding to parameter 'x'; expected Foo but got Int (42) in sub fn at main.raku line 1 in block <unit> at main.raku line 1
librasteve ^^ or here's a subset to do the selection 14:55
ab5tract librasteve: I agree that needing to check for one and only one class membership might point to larger issues in an application’s type design 15:08
But the question itself is quite clearly (to me) not about excluding specific subclasses and rather about excluding all subclasses 15:10
antononcube++ for providing the precise answer
antononcube @ab5tract Thanks! But it was ChatGPT-4 (turbo): 15:14
cdn.discordapp.com/attachments/633...7bd5c&
(I was planning to make certain extensive preaching about getting into the habit of using LLMs with Raku, but just pasting the screenshot above made me less preachy on that subject...) 15:17
ab5tract lol! 15:20
antononcube @hankache Note in the chatbook screenshot above I gave the LLM / ChatGPT exactly the question you posted in the IRC channel. 15:23
librasteve i, for one, welcome our new masters 16:45
lizmat One reason to limit to the exact class, could be for performance reasons 16:56
there are several places in the core where the exact type is checked 16:58
e.g. Date.new contains a fast path for when the invocant is an exact Date type 17:02
because Date subtypes are known to need to standard .bless logic to work correctly
tbrowder ugexe: my $?DISTRIBUTION use has brought up a pesky thing i don't remember seeing. before doing a zef install, while experimenting i'm seeing some confusion in the .precomp directory. it seems a DISTRIBUTION key hangs around even when i get an automatic recompile when i delete some var 19:29
i "cured" the problem by deleting the .precomp dir. is that kind of thing reflected in the installed code? 19:31
i assume not (i hope) 19:32
i was deleting an entry in the "resources" section of the META6.json file but it kept appearing when i interrogated $?DISTRIBUTION until i deleted the .precomp 19:41
ugexe: i can deal with that during dev, but can that happen after a zef installation upgrade (outside of the local repo)? 19:48
ugexe i don't think so 21:47
force reinstalling or upgrading will re-precompile everything 21:48
tbrowder ok, thanks 23:32

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!