We've worried over the years as we build more features into MATLAB, particularly when we new file types and data types, about making sure users are accessing the artifacts they intend to use.
We've even had commands available to help you identify what's going on, such as
Or why? Actually just kidding about the last one being helpful here. But you might enjoy trying this:
Loren knew it was a good idea.
How does MATLAB decide, when it sees a name, whether to use a variable or which of several possible functions with the same name. MATLAB has rules of precedence, and always has. In Release R2019b, the precedence rules were updated. In fact, many o f you were not affected because these changes are somewhat esoteric and are not encountered in lots of code. But when certain conditions occurred in the past, people occasionally got unexpected (from their mental model) behavior. We have tried to fix that with these updated rules. You can find the details in the release notes I noted here, or in these portions of the documentation.
You'll notice in that last link that we provide code examples of what you might have written before, what behavior you saw, how to rewrite it with the new rules, and what behavior you should now see. You'll also notice that the conditions which have changed revolve around variables, nested functions, local functions, and external functions. Some of these changes also strongly promote writing clearer code, such as not naming a local variable and a local function with the same name.
Here are some other instances where some additional precedence rules apply,though I note that these have not changed:
Here are 3 files for one example. We start with the code from 19a or earlier.
This function runs without error in R2019a, with 2 different meanings of local.
function myfunc19a local(1); % local is a function local = 2; disp(local); end function local(x) disp(x) end
This next code errors in R2019b.
function myfuncErr19b % local is an undefined variable local(1); % Errors local = 2; disp(local); end function local(x) disp(x) end
And this code works fine. And would also have run correctly earlier.
function myfuncGood19b localFcn(1); local = 2; disp(local); end function localFcn(x) disp(x) end
This is another change with respect to function behavior, specifically anonymous functions. As of R2019b, anonymous functions can include both resolved and unresolved identifiers.
Hoping we all win, by having cleaner, clearer code, from which we can access the elements (variables and functions) that we are looking for. Did anyone run into issues with this change in R2019b or later? If so, please let me know here.
To leave a comment, please click here to sign in to your MathWorks Account or create a new one.