5

Salesforce provides documentation on the various "reserved words" in the Apex language.

Here they say:

Keywords marked with an asterisk (*) are reserved for future use.

... and then list, for example, "type" with an asterisk.

We already have code that uses "type" as the name of class attributes/properties and as local variables (without the knowledge that this documentation exists) and are now concerned that some future update to the Apex runtime will just break this code.

Often Salesforce protects the developer from future changes by allowing the developer to set the API version in the class's meta file. Has this historically worked when "future use" reserved words became truly reserved (so they cannot be used as identifiers)? I have the feeling this isn't the case, as I cannot use the "when" keyword as a variable name in code with an API version predating the introduction of the Apex switch statement.

4 Answers 4

2

You should be safe with type as a variable name

You can create a Class with Name Type even though a system class with name Type also exists.

public with sharing class Type {

}

If in future salesforce makes Type as keyword then they have to worry about their own System.Type class which people generally use to dynamically create instances of their class

 Type t = Type.forName('MYCLASS');
1
  • 1
    I believe that they probably reserved it exactly for "System.Type" (that was my assumption). I know that right now I can use "type", but this might change in a newer version of Apex runtime. My question about API version protection is still out there...
    – Phil W
    Commented Nov 15, 2019 at 16:36
2

Thanks for calling this out - I see no reason why we'd ever want to make Type a keyword at this point - especially whem that would break System.Type. Almost certain we'll be removing type from the reserved words list. I'll ask for us to double check the rest of the list against the grammar to make sure there isn't anything else miscategorized.

As noted in other answers/comments switch should not be marked as reserved anymore. That was an oversight that I've filed a doc bug to fix.

1
  • Chris, thanks for taking the time to answer this question. I wonder; is "type" the only reserved keyword that is actually usable in code at this point? I ask in case there are others that would cause grief if used as globals in app exchange packages were their status to change...
    – Phil W
    Commented Nov 16, 2019 at 20:59
1

I think you have got an answer on the first part of your question on what "reserved for future use" means, it's exactly what it says. And that you cannot use it if it falls in this category - the only exception I found was with the keyword type (as you have in your question and that Pranay has mentioned)

Regarding your other question around version protection, I did some quick test and it seems a "word reserved for future use" either listed in the doc or whenever it becomes a "keyword", it doesn't get supported in previous API versions as well.

As an example, switch statement is still marked as "reserved for future use" in the doc, but it was released with Summer '18, API version 43.0, so that necessarily makes it a keyword now and not reserved for future use. I wrote the below sample code, saved it with API Version 40.0 to see if having a switch in my class works or not, but it didn't.

// tried saving with API version 40.0
public class APITest {
    public String switch;
}

threw a compile time error:

Error: Compile Error: Identifier name is reserved: switch at line 2 column 19


In summary, it seems to be a good idea to NOT use any word/keyword that is listed in the "reserved keyword" section of the doc.

5
  • Hi @JayantDas, what you have done here is what I already covered in the question regarding the switch statement's "when", also still with a "*" in the document. I think it fair to say this is a significant gap in their compatibility support. Sure, you could claim everyone should have known about this list of reserved keywords, but I only stumbled upon it by chance.
    – Phil W
    Commented Nov 15, 2019 at 21:07
  • I missed that part @PhilW. But I think its the docs where they should just call out -- don't use this!
    – Jayant Das
    Commented Nov 15, 2019 at 21:09
  • Well, they sort of do (as per the snippet I reproduced). Trouble is, they haven't prevented the use of (at least one of) the reserved keywords and I am troubled that they could break lots of existing code if they add that prevention without considering API version. Anyway, perhaps someone from Salesforce might chip in (hah!) with an answer to this?
    – Phil W
    Commented Nov 15, 2019 at 21:12
  • 1
    I should have re-framed my statement. The docs should actually highlight that if any of these still works, better refactor those not to end up with the situation where some seem to work vs. some not.
    – Jayant Das
    Commented Nov 15, 2019 at 21:14
  • There's a big problem with that - globals that can't be changed.
    – Phil W
    Commented Nov 15, 2019 at 21:20
0

It means that at some point in the future, Salesforce may use those as new name of functions or classes in Apex. It's not guaranteed that they will or won't use them, but it's probably a wise decision not to use function names that are in that list on their own.

1
  • 1
    I think it means they may add specific language keywords in the future (not just functions or classes), like they have with "when". Unwise or not, we have already got plenty of code that uses "type" as various identifiers, and this works. My concern is that this might change in a newer version of Apex. My question about API version protection is still out there...
    – Phil W
    Commented Nov 15, 2019 at 16:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .