If implemented it should have a better name than #or. At least for my understanding #or would be the same as {{#if:{{{title|}}}{{{name|}}}|Any of them is not empty|Both of them are empty}}, so a less confusing name would be better.

It would be really important to be able to validate much more real-world use-cases for this, as well as have links to talk pages where this have been requested by the community. I also have to support the previous comment: Just calling this "or" does not sound right.

In T201878#4512875, @Agabi10 wrote:

If implemented it should have a better name than #or. At least for my understanding #or would be the same as {{#if:{{{title|}}}{{{name|}}}|Any of them is not empty|Both of them are empty}}, so a less confusing name would be better.

This isn't correct. As requested, the code {{ #or: {{{title|}}} | {{{name|}}} | {{PAGENAME}} }} would be equivalent to

{{ #if: {{{title|}}}
  | {{{title}}}
  | {{ #if: {{{name|}}}
    | {{{name}}}
    | {{PAGENAME}}
  }}
}}

Note that this means that {{{title}}} and {{{name}}} each have their own "this exists" branch, and the entire second branch (the check for {{{name}}} existing) would not be followed if {{{title}}} exists. This is a significant difference from your understanding.

I do agree the name #or is not ideal, though I'm short on suggestions for better names - the best I can come up with is some variant of "firstexists", but that doesn't seem very satisfactory.

In T201878#4513141, @Dinoguy1000 wrote:

In T201878#4512875, @Agabi10 wrote:

If implemented it should have a better name than #or. At least for my understanding #or would be the same as {{#if:{{{title|}}}{{{name|}}}|Any of them is not empty|Both of them are empty}}, so a less confusing name would be better.

This isn't correct.

I know the requested behavior and my understanding don't match, what I tried to tell is what I would think the #or parser function would be doing when I found it in wikitext if implemented that way. That's something to take into account before setting that name to the function and preferably named differently to prevent that kind of confusions.

In T201878#4513141, @Dinoguy1000 wrote:

I do agree the name #or is not ideal, though I'm short on suggestions for better names - the best I can come up with is some variant of "firstexists", but that doesn't seem very satisfactory.

I think #firstexists would be way more descriptive than #or. The problem with that name is that it might create confusion with how #ifexists behaves. What about #coalesce as in many SQL databases?

In T201878#4513148, @Agabi10 wrote:

I know the requested behavior and my understanding don't match, what I tried to tell is what I would think the #or parser function would be doing when I found it in wikitext if implemented that way. That's something to take into account before setting that name to the function and preferably named differently to prevent that kind of confusions.

Aah, my apologies for misunderstanding you then! ^^;

In T201878#4513148, @Agabi10 wrote:

I think #firstexists would be way more descriptive than #or. The problem with that name is that it might create confusion with how #exists behaves. What about #coalesce as in many SQL databases?

I'm not familiar with #exists; did you mean #ifexists?

I figured there might be preexisting terminology for this type of functionality in some programming language or another, but had no idea what it might be or how to go about looking for it. Looking around a bit now that I have "coalesce", though, suggests this functionality is a variant of the null coalescing operator (maybe an extended Elvis operator?), so that name definitely makes sense. I am worried, though, about how intuitive it might be for people with little background in programming (though this might be an unavoidable issue no matter what name we choose).

In T201878#4513160, @Dinoguy1000 wrote:

I'm not familiar with #exists; did you mean #ifexists?

Yes, I just edited the answer to fix that.

In T201878#4513160, @Dinoguy1000 wrote:

I figured there might be preexisting terminology for this type of functionality in some programming language or another, but had no idea what it might be or how to go about looking for it. Looking around a bit now that I have "coalesce", though, suggests this functionality is a variant of the null coalescing operator (maybe an extended Elvis operator?), so that name definitely makes sense. I am worried, though, about how intuitive it might be for people with little background in programming (though this might be an unavoidable issue no matter what name we choose).

Yes, it's exactly that. And I don't think it's really a problem that it might be confusing for people with little background in programming. Once they get used to the naming it's less confusing than the existing <includeonly> and <onlyinclude> tags.

I chose #or as possible name for a function like that, because it is used this way in many coding languages, for example:

• JavaScript
• PHP

So, I think it isn't that unintuitive. Furthermore, I think many parser functions defined in this extensions already don't have the most intuitive behavior themselves.

(Note that I didn'T see the last 3 hours of comments before submitting this.)

In T201878#4513120, @thiemowmde wrote:

It would be really important to be able to validate much more real-world use-cases for this, as well as have links to talk pages where this have been requested by the community. I also have to support the previous comment: Just calling this "or" does not sound right.

It should be fairly easy to make a statistic how many (and how deeply) nested #if parser function occur on enwiki and some other sites.

In T201878#4513160, @Dinoguy1000 wrote:

I figured there might be preexisting terminology for this type of functionality in some programming language or another, but had no idea what it might be or how to go about looking for it. Looking around a bit now that I have "coalesce", though, suggests this functionality is a variant of the null coalescing operator (maybe an extended Elvis operator?), so that name definitely makes sense. I am worried, though, about how intuitive it might be for people with little background in programming (though this might be an unavoidable issue no matter what name we choose).

#coalesce would be another possible name, although I don't like that it's much longer than simply writing `#or'. An additional advantage of the latter that according to enwiki Lua uses a similar syntax for this thing, so it would be consistent with Scribunto.

So, finally catched up ^^

I'd recommend addition of new parser functions, no matter the use case.

[..] Lua uses a similar syntax for this thing, so it would be consistent with Scribunto.

Since you mention Lua and Scribunto, did you encounter an issue with Lua that made you prefer wikitext?

EDIT: I meant to say, I'd recommend against addition of new parser functions.

In T201878#4513462, @Krinkle wrote:

I'd recommend addition of new parser functions, no matter the use case.

Did you accidentally a word there? Given we do have Scribunto and Lua now, I'd kind of expect you to be against addition of new parser functions, not in favor.

In T201878#4513462, @Krinkle wrote:

Since you mention Lua and Scribunto, did you encounter an issue with Lua that made you prefer wikitext?

I don't have any knowledge of Lua specifically, but just happened to notice this information. However, I recently got to know Lua a little bit while looking after T201171.

I prefer wikitext as it's more standard and more portable to third-party wikis than Lua. Furthermore, there are much more users who are able to work with wikitext templates than with Scribunto invocations.

In T201878#4513464, @Dinoguy1000 wrote:

In T201878#4513462, @Krinkle wrote:

I'd recommend addition of new parser functions, no matter the use case.

Did you accidentally a word there? Given we do have Scribunto and Lua now, I'd kind of expect you to be against addition of new parser functions, not in favor.

Assumed you both missed a word there: What is your rationale against the addition of new parser functions?

Indeed. I'd recommend against addition of new parser functions for logic and string operations.

Changing project tags to just ParserFunctions since this is where #if, #ifeq, etc. are implemented.

In T201878#4513120, @thiemowmde wrote:

It would be really important to be able to validate much more real-world use-cases for this, as well as have links to talk pages where this have been requested by the community. I also have to support the previous comment: Just calling this "or" does not sound right.

As I wrote in the duplicate task, this has been validated by many wikis using a template for that.
Also, some frequent templates were recently integrated as built-in features to reduce the number of transclusions.
https://en.wikipedia.org/wiki/Template:If_empty/doc also provides a nice summary for why such a feature is useful (DRY).

As for the name, I suggest alternatives, such as #coalesce (T201878#4513193), #ifempty (name of the template), #nonempty, or #first.