The syntax rules of TeX allow for certain primitives to have an “argument” delimited by \bgroup or \egroup. The main examples are
\hbox, \vbox, \vtop, \vcenter, \halign and \noalign.
This is the basis where, for instance, \halign LaTeX builds tabular on: with \begin{tabular}{<arg>} the argument is transformed into a suitable preamble for \halign and then, besides other things irrelevant for this discussion, TeX executes
\leavevmode$\vcenter\bgroup\halign\bgroup<built preamble>\cr
and, when \end{tabular} is found,
\crcr\egroup\egroup$
is performed. The \vcenter can be \vbox or \vtop depending on the option given to tabular. Of course, this possibility is exploited also in lrbox.
Other primitive commands accept an argument in the form of a <general text> and the TeXbook describes this as
<filler>{<balanced text><right brace>
where <filler> is an arbitrary sequence of \relax and space tokens, { means an implicit or explicit token with category code 1 (so either { or \bgroup) and <right brace> means an explicit character token of category code 1.
Examples of primitives with this are \uppercase, \message, \write and \mark, besides assignments to token registers:
<token variable><equals><general text>
So you can't define a macro based on \uppercase whose argument is delimited by \egroup, but you can do it with \hbox.
Worse, for your plan, is the fact that the replacement text in a macro definition must be delimited by explicit character tokens of categories 1 and 2 respectively.
Note that there is a rule of thumb for knowing which primitives accept \egroup as final delimiter: those where the argument is enclosed in an implicit group (with a quirk about \halign because \tabskip assignments will be performed outside this implicit group). This is the case also for the primitive actions of _ and ^, by the way.
It's impossible to define a general macro whose argument can be delimited by } or \egroup. An apparent argument can, provided the replacement text ends with a primitive accepting \egroup in the first place; \aftergroup trickery can then be used for completing the task. Just to make a silly example, here's an implementation of \vfbox that takes a named color as optional argument:
\documentclass{article}
\usepackage{color}
\makeatletter
\newcommand{\vfbox}[1][black]{%
\def\vfbox@color{#1}%
\setbox\vfbox@box=\hbox\bgroup
\aftergroup\vfbox@do
\let\next=
}
\newcommand{\vfbox@do}{%
\begingroup
\color{\vfbox@color}%
\fbox{\box\vfbox@box}%
\endgroup
}
\newbox\vfbox@box
\makeatother
\begin{document}
\vfbox\bgroup abc\egroup
\vfbox{abc\egroup
\vfbox[blue]\bgroup abc}
\end{document}
But you can't do it with \uppercase (besides its limitation).
<general text>must end with an explicit brace, not\egroup. For font changing or box making commands it is actually easy, but delimiting an argument of a general macro either by\egroupor}₁ is difficult, if ever possible. And I'm really dubious about its usefulness. – egreg Aug 17 '14 at 20:35{]than\bgroup\egroupand much easier and more robust to define commands using that form why would you want to do this? your question gives no indication of any possible reason or potential benefit. – David Carlisle Aug 17 '14 at 21:50\hbox). – Manuel Aug 18 '14 at 09:48\hbox\bgroup…\egroup, I think it might be useful (although it's true that we have survived all these years without it :D). – Manuel Aug 18 '14 at 09:50\hboxis completely different and closer to grouping than to delimiting arguments. – David Carlisle Aug 18 '14 at 09:52|…verbatim#1\end{verbatim}[…]which is IMO quite fragile, and anything better than that would be great. For instance, something that works likea_\mathrm{min}but in a user created command would be welcome. – Manuel Aug 18 '14 at 09:58a_\mathrm{min}is just such horrible markup (and greatly limits what you can do with the^and_syntax:-) So many uses (for language shortcuts or html generation or ...) want to overload_and^with active characters with macro definitions and it's not possible to recreate that syntax sensibly using a macro. If users used the documenteda_{\mathrm{min}}form, it would be trivial to overload_. – David Carlisle Aug 18 '14 at 10:01^and_to adjust them to my needs), it was just an example of what the question asks. – Manuel Aug 18 '14 at 10:07\def, or similar defining commands, behave in a very different way from native commands; the latter accept the balanced braces as well as the balanced\bgroupand\egrouppairs, even if these implicit braces are used inside different macros, for example the opening and the closing macros of an environment. Parsing macros for finding their arguments is not the same as processing their arguments by native commands. – Claudio Beccari Aug 18 '14 at 09:08{<balanced text>}as argument accept\bgroupor\egroupin place of{or}(\hbox, for instance). Primitives that have<general text>as argument, only accept\bgroupas a replacement of{, but require}at the end (\uppercase, for instance). Some primitives (the\deffamily) have an argument that must be delimited by explicit braces. – egreg Aug 18 '14 at 09:19\Open\Closemacro from http://tex.stackexchange.com/questions/196071/macro-to-close-all-open-environments-groups-and-argument-delimiters . But I'am not sure the serviceability of this. These two types of separators will be used only for parameter scanning (without total expandning). The point of these two separators in primitives are that these separators are scanned during total expansion (for example\egroupis in a macro expanded later). For examplea_\mathrm{min}doesa_\bgroup something\egroupafter expansion, no during parameter scanning. – wipet Aug 31 '14 at 09:48