I wonder what was intended with these extended identifiers?
https://github.com/Raku/problem-solving/issues/224* - Extended
identifiers-why and where, exactly?*
-y
On Fri, Aug 28, 2020 at 8:26 AM Ralph Mellor <ralphdjmel...@gmail.com>
wrote:
> I don't think you're supposed to be able to have extended identifiers
> as named parameter/argument identifiers. They are meant for a few
> specific scenarios where there's special value in having adverbs aka
> pairs embedded in identifiers:
>
> * Alternations in grammars. Typically of form `foo:sym<bar>`.
>
> * Appending :api<>, :auth<>, :ver<> to package identifiers.
>
> They *may* work in a couple of other scenarios but in general,
> don't do that.
>
> By the way, "attributes" has a specific meaning in Raku, namely the
> fields of object instances.
>
> --
> love, raiph
>
>
> On Wed, Aug 26, 2020 at 1:31 PM Marcel Timmerman <mt1...@gmail.com> wrote:
>
>> Hi everyone,
>>
>> I was experimenting with extended identifiers and found that it is not
>> possible to use it in named attributes. E.g.
>>
>> > sub a (:$x:y) { say $x:y; }
>> ===SORRY!=== Error while compiling:
>> Unsupported use of y///. In Raku please use: tr///.
>> ------> sub a (:$x:y⏏) { say $x:y; }
>>
>>
>> > sub a (:$abc:def) { say $abc:def; }
>> ===SORRY!=== Error while compiling:
>> Invalid typename 'def' in parameter declaration.
>> ------> sub a (:$abc:def⏏) { say $abc:def; }
>>
>>
>> Is there a trick of some sort to get this done? At the moment I can only
>> use a slurpy hash and check for its keys. This is good enough for me but
>> out of curiosity I ask. If not possible, an extra note in the documentation
>> on named arguments would be necessary.
>>
>> regards,
>> Marcel
>>
>>
>>
