I have chronic Fat Finger Syndrome and am used to compilers yelling at me for misspelling routines (aka, get undefined symbols). I had this problem when I was setting up a fragment function (via library.makeFunction) and didn’t notice I fat fingered the name. No errors. Sure, I could have checked if the makeFunction returned nil, but I though that maybe something would die a catastrophic death and point to my mistake. Instead, stuff just ran quietly along until I found out that target texture was all messed up (it was not really a visible texture). Is there a way (or an Xcode feature) that I could turn “on” that wouldn’t just noop in cases like this? Or, I guess it’s up to me to do the “right” thing and harden my code (which would be useless extra code once I knew stuff was working right).
I am actually surprised you didn’t get a run time error if the fragment function name was wrong.
Although I just changed the name of a fragment function in a working project and it didn’t crash (16.1 beta). I’m sure it used to.
We should probably be checking that the function is not nil, because that is pretty catastrophic.
The only thing I can think of is to have a file that only defines Swift function strings so you can easily check them against the Metal Shader files, and then use that name when you define the function.
Otherwise, just do the right thing 
.
Ok, thanks. It drove me nuts for a bit. I thought Xcode (16.0) would have caught it. Anyway, maybe something to consider for your 5th edition (put in those nil checks for .makeFunction calls).