'compgen' appears to have undocumented parameter '--', can I rely on it being present across systems?

I happen to be on *Ubuntu 18.04*, with *GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)* The output of

% compgen -A file --
test-data
foobar
--

outputs all files/dirs in the current directory as though no token to complete was passed. However, the call

% compgen -A file -- --
--

correctly outputs either nothing or --* depending upon whether or not there is actually a file/files --\* present. (NOTE: Trying pass '--' using the '-W' parameter doesn't help. The relevant [gnu man page](https://www.gnu.org/software/bash/manual/html_node/Programmable-Completion-Builtins.html) and [ubuntu man page](http://manpages.ubuntu.com/manpages/xenial/man1/bash.1.html) are identical - > compgen [option] [word] > > Generate possible completion matches for word according to the options, which maybe any option accepted by the complete builtin with the exception of -p and -r, and write the matches to the standard output. When using the -F or -C options, the various shell variables set by the programmable completion facilities, while available, will not have useful values. > > The matches will be generated in the same way as if the programmable completion code had generated them directly from a completion specification with the same flags. If word is specified, only those completions matching word will be displayed. > > The return value is true unless an invalid option is supplied, or no matches were generated. It appears as though the -- parameter works as an optional delimiter to show where the partial begins, but it is also interpreted as an 'illegal option` with regards to the return status. It's easy enough to put in the extra -- to work as a delimiter so that -- is interpreted correctly, but can I rely on the -- to always be required across different bash versions and/or linux (or unix) systems?