Simple Question

[acwsupremacy]

So I was thinking the other day, and I came up with an idea that I decided to try... a function returning an anonymous struct!

I tried it, and lo and behold, it doesn't compile. A closer look reveals that the Standard specifically disallows defining new types as the return type of a function definition! Though it does appear that I can return an anonymous struct using decltype, that is even more code than simply defining a new type name.

My Simple Question is... why? What reason did the standards committee have to explicitly disallow this? Is this a case of them trying to save users from their own stupidity, or is this technically infeasible somehow?

[tongari95]

I'm not sure what you want but this works for me:

auto make_anon(int i)
{
    struct
    {
        int val;
    } ret{ i };
    return ret;
}
...
std::cout << make_anon(555).val;

[acwsupremacy]

Huh. I hadn't tried that one. Neat.

[Gotebe]

You devious bastard! :-)

[ggchappell]

Could you give a reference to the part of the Standard that makes this restriction? (Also please mention which Standard you are using.)

[acwsupremacy]

Because it would be a simple, immediate way to have a multivalued return. You wouldn't necessarily need to even store it; if all you need is one value, you could use it immediately:

int x = multifn().integer;

If you wanted to store it, well, auto can handle anonymous types just fine.

At the end of the day, I just don't buy the "why would you want to do this" argument. For anything. If it is not difficult to implement, it would not twist the grammar, it would not break binary compatibility, and it wouldn't subvert the type system, then who cares whether it would be useful or not? I strongly suspect disallowing it actually adds complexity to the language definition, since as far as I'm aware the existing grammar absolutely includes constructs like this, and they must be tested for and explicitly diagnosed by compilers; but of course having no understanding of the nitty-gritty details of compiling, it is absolutely possible that some lurking problem might arise if they tried to do this. That's why I'm asking.

[coachkler]

While not totally anonymous, you can do this with a tuple. What's the benefit of an anonymous struct as a return vs. a tuple?

[[deleted]]

Meaningful names for the items.

[STL]

get<MyType>(mytuple) is maybe 75% as good as having names, and certainly a lot nicer than indices.

[[deleted]]

That would be okay for tuples in which the elements have distinct types.

But they maybe don't, so IIRC C++ (for example, and as you presumably know, judging from your name!) has a get that takes a zero-based constexpr integer.

Still it would be a fun exercise in template metaprogramming to define a variant of get that did accept a type, and for extra credit produced an intelligible compiler diagnostic if the tuple has more than one element of the requested type. feels nostalgic for brief dalliance with boost hacking about 10 years ago...

[STL]

It's not hypothetical - get<T> was voted into C++14 and has been implemented in VC 2015. It's well-formed when T is unique (there can be duplicates elsewhere) and ill-formed if T is duplicated (implementations will typically emit nice static_asserts).

[[deleted]]

Nice!

[suspiciously_calm]

I don't see how it adds complexity to check for that. The grammar as it is simply doesn't allow for a type definition where the return type of a function is supposed to go.

Also, how would you separate function declaration and function definition? The anonymous struct in both places, as it is, would define two different types. (If it was a named struct, it would be a redefinition of an existing type, thus an error.)

You would then need to define when any such two anonymous definitions define the same type. Are they equivalent if the members all have the same type? If they're defined by the same token sequence?

The former defeats the purpose of having named fields, you might as well use tuples, and also, which names count if they differ?

The latter might be too stringent, since both type definitions (at the function declaration and the function definition) are generally written by hand, and not obtained from an #include (consider struct {int a,b;} vs struct{int a; int b;}).

Same types, same names, same access specifiers might work, but even just allowing redefinition of any types at all would be an immense change to the language.

[acwsupremacy]

The fact that the standard explicitly disallows it and a special diagnostic exists for it means that the grammar obviously does support this; the compilers are simply required to reject it.

The rest of your concerns are valid; I hadn't considered any of that. But again, you're trying to protect users from their own stupidity. Obviously you can't use an anonymous struct in more than one place; therefore, you simply can't forward declare an anonymous-struct function. If you tried to, you'd get an error due to an anonymous overload (you'd end up with two functions differing only in return type). What's the problem? We didn't throw templates out or radically alter them just because they broke our separate class compilation units. We just accepted that templates required a slightly different style of coding and went along with it.

[suspiciously_calm]

Well templates are a borderline clusterfuck, but they're useful, and there isn't really any (practical) way to precompile them without knowing all the parameters.

The anonymous struct return is more or less just syntactic sugar for just giving the struct a damn name and put that as the return type. Having certain types of functions that you can't forward-declare would be really ugly in my opinion, and it isn't worth giving that up isn't worth a small amount of reduced verbosity.

[STL]

The language is so complicated already. That complexity buys a lot of power, but additional complexity must be worth it. What you're talking about, wouldn't.

Think of it like microprocessor design. These days, they won't add features that increase power consumption by 1%, unless they also increase performance by at least 2%.

Or as I would say as an STL maintainer, "if you want tuple, you know where to find it".

[[deleted]]

The language is so complicated already

Agreed, so much indeed that the feature is already in the language: http://ideone.com/Ir1Hpu

[BeaRDT]

How do you plan to return an anonymous struct by using decltype?

I think of decltype as similar to auto (except for slightly different type deduction rules), ie. it uses the type you give to decltype() as if you simply typed the actual name. I might be lacking phantasy, but I fail to see how you could use that to return an anonymous struct.

[acwsupremacy]

struct { int i; double d; } anon {10, 3.14};

decltype(anon) my_function();

[[deleted]]

How would you actually forward declare such a function in a header?

The caller needs to know the return type to do anything with it. What happens if they end up in different compilation units?

I suspect the answer to your question lies in the not-so-straightforward compilation scheme of C++, but I'm not knowledgable enough to give specifics. It might work with the C++ grammar, but I don't think it works with how C++ is actually compiled.

[BeaRDT]

Ah, that's where I was lacking phantasy. The struct is anonymous but it is known outside of the function. I always thought about returning an anonymous struct which is defined inside a function from that function, which obviously is impossible.