<p dir="auto">The original motivation for this is having a nicer syntax for <code class="notranslate">transpose</code> and <code class="notranslate">conj</code>, where the most appropriate I could come up with was <code class="notranslate">M'ᵀ</code> and <code class="notranslate">z'ᶜ</code>. Currently this would only be possible by special casing <code class="notranslate">transpose</code> and <code class="notranslate">conj</code> at a parser level, but if <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="512825578" data-permission-text="Title is private" data-url="https://github.com/JuliaLang/julia/issues/33683" data-hovercard-type="pull_request" data-hovercard-url="/JuliaLang/julia/pull/33683/hovercard" href="https://github.com/JuliaLang/julia/pull/33683">#33683</a> was merged, one could extend the concept of Unicode modifiers for infix operators to <code class="notranslate">'</code> very nicely. This would also be useful for packages like Zygote, which like to pun on <code class="notranslate">'</code> as notation for taking the derivative, which could then export e.g. <code class="notranslate">'ᴰ</code> instead.<br>
A problem is that currently, <code class="notranslate">a'ᵀb</code> is valid syntax for <code class="notranslate">adjoint(a) * (ᵀb)</code>, which is quite unfortunate, since this is different from other infix operators like <code class="notranslate">+</code>, where the modifier gets parsed as part of the operator, even if there is no whitespace in between. I therefore believe that parsing these as part of the operator will make for more consistency, but as this is technically breaking, it might be necessary to deprecate this syntax for one minor release first. Eventually it might make sense to disallow modifiers in front of variable names altogether, but that would be a separate issue.</p>
<p dir="auto">Since <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="231709084" data-permission-text="Title is private" data-url="https://github.com/JuliaLang/julia/issues/22089" data-hovercard-type="pull_request" data-hovercard-url="/JuliaLang/julia/pull/22089/hovercard" href="https://github.com/JuliaLang/julia/pull/22089">#22089</a> it is possible to add suffixes to existing binary operators in order to create entirely new ones.</p>
<p dir="auto">If it were possible to add suffixes to the postfix <code class="notranslate">'</code> operator as well, then that would make it possible for the user to create an arbitrary number of new postfix operators. For example, it would make it possible to make <code class="notranslate">A'ᵀ</code> the transpose of <code class="notranslate">A</code>.</p>
<p dir="auto">See <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="214439569" data-permission-text="Title is private" data-url="https://github.com/JuliaLang/julia/issues/21037" data-hovercard-type="issue" data-hovercard-url="/JuliaLang/julia/issues/21037/hovercard" href="https://github.com/JuliaLang/julia/issues/21037">#21037</a> for the beginning of this discussion. Here's a brief summary as best as I've understood: The original proposal was to map <code class="notranslate">x'</code> to the function call <code class="notranslate">'(x)</code>, and then allow suffixes on that function name, but this is not possible.  The first character of an identifier cannot be <code class="notranslate">'</code>, because <code class="notranslate">'</code> is already used to introduce character literals. On the other hand, using a function name like <code class="notranslate">apostrophe</code> can lead to problems similar to <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="295470843" data-permission-text="Title is private" data-url="https://github.com/JuliaLang/julia/issues/25947" data-hovercard-type="issue" data-hovercard-url="/JuliaLang/julia/issues/25947/hovercard" href="https://github.com/JuliaLang/julia/issues/25947">#25947</a>. That problem can be avoided by mapping to <code class="notranslate">Base.apostrophe</code> instead of using the local scope.</p>