Should return checks assume !VOID by default?

[Ovid]

When typing out example code, I often find myself typing this:

sub get_something( uuid $uuid ) return OBJECT[Some::Class] & !VOID {
    ...
}

I hate typing and explaining the & !VOID because it's usually not the point of the example, so sometimes I skip that. But that makes me uncomfortable because any time I have a return type, I pretty much assume that it needs to be used in some way, or else the return type doesn't make sense. In fact, for most of my code, this is the case, with the exception of chained mutators (see below).

I was thinking what does make sense is for any returns to assume & !VOID by default. Instead, if you wish to allow it to be called in void context, you express that:

method set_value (Str $key, Defined $value) returns OBJECT[This::Class] & VOID {
    ...
}

From the above, with Corinna syntax, set_value can be a chained mutator, but it's ok to to call it standalone, in void context.

[happy-barney]

as far as Perl doesn't have representation for void, and common pattern is return unless can continue, I'd say void should be opt-in and probably replaceably by Maybe[Object[This::Class]]

such method should anyway evaluate as undef in scalar context and empty list in list context, inability to return call_void_function() is pain in the ass in languages like C/Java.

[Ovid]

I can't tell if you are saying yes or no. I think you're agreeing with my suggestion that if we have a return type, we should assume that calling in void context is an error. Are you agreeing with that?

[happy-barney]

Although it makes sense for that scenario I'd go with opt-in feature on its own.
Can we make a survey which languages supports calling non-void in void context? (eg: plpgsql doesn't support it)

Also there should be syntax to explicitly allow that, eg (using C/C++ to help): (void) non_void (...), for example DB store function which returns constructed object throwing exception on error. I can imagine too conservative developers prohibiting void return value ... and I can imagine also scenarios where I need only side-effect.

I was talking about opposite situation, calling sub declared as void in expression where void is allowed (eg: return, last statement, list context, ...)

[druud]

Re. "prohibiting void return value", to me, in Perl, there is no such thing. In a void calling context, the (implicit or explicit) return value gets ignored. So void is not about the return value, but about the calling context.

The check on the return value could (for example) require an empty list in void context. Imagine a sub that ends with conditional lines (... if DEBUG;), which could then make the return-value-check fail only if DEBUG is true.

[druud]

VOID can be CONTEXT_MAYBE_VOID and CONTEXT_MUSTBE_VOID, as it is a condition on the calling-context. In void context, the thing is free to return any value, as it will just be ignored. Also consider CONTEXT_LIST and CONTEXT_SCALAR. See wantarray().

Also be aware that if there is a die() or an exit() (or POSIX::_exit, or exec(), etc.) involved, a sub ends without returning a useful value.

[Ovid]

I can't tell if you are saying yes or no. I think you're not agreeing with my suggestion, but I'm not sure. Also, CONTEXT_MAYBE_VOID and CONTEXT_MUSTBE_VOID are awfully verbose compared to what we have now.

[druud]

I think it must be clear that the VOID notion is about the calling context (which can be multiple levels deep), and not about the return value, and also not about how the sub presents its return value.

I also think that, by default, the value-check must always be done, even if the context is VOID, unless the value-check includes that in VOID context anything goes. A strict value-check could include that in VOID context only an "empty list" return is valid.

So to me, VOID is not about the way that the sub returns a value, implicitly or explicitly.