In C, { "Avril", 2500 } is an initializer. You are allowed to use it at the point where you declare and define a structure variable, for example. But you can't use it in an assignment statement later on. Semantically, they may be very similar and you are wondering why you can't do it. But it's just a matter of the allowed syntax. You can initialize structures and arrays of structures, even. But you can't just place that into an assignment statement because they chose not to make it legal.
It's not for the reason James Bond says. Your structure actually specifies the size of the character array and his example doesn't. In other words, the compiler can tell in your example how much memory is required, but not in his case. So he's talking at cross purposes. He's correct in telling you that it doesn't work like that, but the reason he gives isn't correct.
Initializers are a necessary convenience for static lifetime variables and variable arrays. How else would you set up values there before main() starts up and code can execute? Without parsing and compiling support for that, you'd be forced to add code to initialize every single value. That would add lots of code you write, generate lots of executable code too, and increase the cpu load for no good reason. And this would certainly cause a lot of trouble back in the day when memory was expensive and scarce (when C was being created.)
Once the initializer syntax was supported by the parser, it was easy to let it do the same parsing work within a function. The only remaining question was about what to do in the case of function instance lifetime variables and variable arrays (automatic variable types.) Unfortunately, initializers for those types of variables creates code and uses the cpu, unlike the case for static lifetime variables. Because every time you enter a function, all of the function instance variables may take any value to start (consider them random.) So the initializers given result in a series of equivalent statements needed to initialize each and every value, one by one -- and that requires code. It's almost as though you did the work yourself, except more convenient. However, the compiler is allowed a little leeway in HOW it does it.
But the primary reason for going to all the trouble of having initializers wasn't for function instances, but for static lifetime types where it makes abundant sense. (Since you can't escape the run-time cost for function instance variables, they probably would have not even allowed the syntax had static lifetime variables not existed in the language. They would have just asked you to write the lines of code to initialize them.)
So then the question you bring comes up. If you've done the necessary thing of allowing initializers for static lifetime stuff and already caved in and permitted initializers (for free, effectively) for function instance stuff, then what about allowing initializer syntax in an assignment statement?
The whole reason for doing it in the first place was about NOT having to generate run-time code for initializing statics. The only reason you allowed the syntax in function instance variables was because it "came for free" and was "consistent." That doesn't mean you support the syntax in a new situation. The assignment statement is rather complex, too. You can assign to multiple l-values at once. And every assignment statement itself supplies an r-value as a result. There just didn't seem to be a solid reason to complicate the compiler for this. You can just write out the assignments yourself. And it's not commonly done, anyway. Better to just stick with the basics.
Static lifetime variable initialization can be done at compile time. This means the compiler can map out the needed binary bits beforehand and place them all into a big block that has the same size and order as the allocation for the static lifetime variables. When the operating system runs the program, it just loads that big block of bits as a huge chunk (the linker will already have correctly aligned all the static lifetime variables to point to the right places inside that block.) So no extra code is needed. Just load and go. But function instance variables cannot be handled that way. They don't have "starting" or "default" values, as they are created on the spot when the function starts up and the fastest way to do that is to NOT initialize them, at all. So C doesn't initialize them. It just allocates them. So it's normally your job to assign values into them before using them. But you are gifted with the initializer syntax, luckily. That leaves the compiler with the problem of generating all those assignment statements that would otherwise be needed to do the same work. And the C compiler does, too.