in reply to Re^2: RFC: "assignary" operator ?= :
in thread RFC: "assignary" operator ?= :

> not ternary, just "binary",

yes it's binary.

> $var1 ?= die "ERROR: \$var1 already set." : $var2;

Thanks for demonstrating your use case, it's even stranger than I expected! ;-)

die will not return a value - actually it won't return at all.

> Maybe you'll see more elegant way how to do such thing.

Yes with a properly named custom-function operating on an alias.

something like 

 
sub init { 
   die "ERROR: \$var already set." if defined $_[0];
   $_[0] = $_[1];
}

init $var1 => 'value1';  # pretty elegant, right?
init $var2 => 'value2';
init $var3 => 'value3';

[download]

Please note the defined° , cause else wise you'd miss false values like 0 or "". (which renders your requirement for a new operator a bit useless)

UPDATE:

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

°) a shorter way would have been $_[0] // die 'ERROR: ...';

Off by one, it's the inverted case :)

Replies are listed 'Best First'.
Re^4: RFC: "assignary" operator ?= :
by shmem (Chancellor) on Dec 07, 2019 at 17:38 UTC
    Yes with a properly named custom-function operating on an alias. 
    init $var1 => 'value1';  # pretty elegant, right?

    [download]

    No, not at all. First, init() is a poor name which doesn't, by name, tell at all what it is doing. Second, the sub you wrote isn't at all ternary in any way, since it misses $_[2]. Third and last, function LIST doesn't tell at first glance that it is about conditional assignment to $_[0] from either $_[1] or $_[2] based on defined-ness of $_[0].

    perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
[reply]
[d/l]
[select]
      > Second, the sub you wrote isn't at all ternary in any way

      It's an XY problem, the use case wasn't ternary from the beginning.

      But you're welcome to impress us with a better solution.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

[reply]
Re^4: RFC: "assignary" operator ?= :
by richard.sharpe (Sexton) on Dec 07, 2019 at 22:13 UTC

    Thank you, Rolf (and also other guys).

    Personally I'd prefer for such "basic thing" something "exactly explicit" just where it's used, without packaging/hiding it in the subroutine defined elsewhere. I prefer using custom subroutines for bit less simple logic (just personal preference).

    About no return from dying: yes, I really don't need returning from that death, therefore I called that "exploiting". But maybe somebody will find also other use cases for such "assignary" operator, not just this one.

    In the context of my practise (as used in my scripts and modules), I initialize (define) all my local variables just with heir my, to be more explict, what type of value are they predetermined to bear (number, string, hashref, etc.), e. g.:

    my $string = '';

    and therefore I don't need to differentiate undef from '', which means "not set" in my example.

    But, in case, of undefined variable used in assignary, e.g.:

    my $some_undefined_var; $some_undefined_var ?= die 'already set' : 'survived';

    on my opionion, it could stay alive, and "use of uninitialized value" warning raised on use warnings;.

[reply]
[d/l]
[select]

In Section Meditations