search

AdaCore / ada-spark-rfcs

Platform to submit RFCs for the Ada & SPARK languages
63 stars 28 forks source link

[RFC] case statement with renamed type values #36

Open GyorgyRotter opened 4 years ago

GyorgyRotter commented 4 years ago

https://github.com/GyorgyRotter/ada-spark-rfcs/blob/rfc_case_statement_with_renamed_type_values/considered/rfc-case-statement-with-renamed-type-values.rst

yannickmoy commented 4 years ago

Hi @GyorgyRotter can you reformat your PR? It does not display well correctly, which makes it hard to follow. See the link at the top for how it is displayed currently. thx

GyorgyRotter commented 4 years ago

Hi, please check and read it

yannickmoy commented 4 years ago

I fear that others will consider it confusing that you can use "a | a" in a case statement or expression. It seems that the current workaround that you mentioned of using "a .. x", in the quite special case you refer to where x is a renaming of a (and you don't have more renamings), provides what you need, except for the syntax using | instead of ..

GyorgyRotter commented 4 years ago

Hi, I think if the compiler could distinguish between the a and it's renamed type value x we may exclude such cases. In this case to refer the same type value could be forbidden in this "a | a" form but could be allowed in "a | x" form. This could make possible to use multiple renames what the current implementation does not make possible by .. when we are writing this "when a .. x | a .. y" (where "y" is an other rename for "a"). Currently if I understand well for the compiler it is totally equivalent to "when a .. a | a .. a" which is forbidden because of "when a | a" was also forbidden. With this distinction could produce more readable code in the case of e.g. complex state machines when we could look at the name of the states from different perspectives and we would like to express it in our case statement. I think it would be a nice feature.

yannickmoy commented 4 years ago

Hi @GyorgyRotter. I suggest you try to get support for this feature from other Ada developers, so that they weight in this discussion. Otherwise, I fear most people may just push back due to the possibility for undesirable ambiguities that would be possible with this change.