Epic just make an announcement about version 1 of verse. I am writing to note the changes and thoughts
The version 1 upgrade is not mandatory, you can stay at current version until Epic decides to stop the support. Ideally, you want to be on top of version, so upgrade asap in a different branch is probably the best thing to do. I don’t expect a new version to come up every other week, so it shouldn’t be too much.
- Failure in Set
- Set no longer allow failable expression
- Now you want to store the result from failable expression to a variable with an “or” keyword to store a default value when the expression fails
- This should be things more defined, but I wonder if we can do
set X = FailableExpression[] or default
instead of making a new variable
- Failure in Map Literal Keys
- I think the page got a typo on there sample code there. They probably mean
map{ExpressionThatCanFail=>Value}
as the old code that is allowed before version 1 - Another change to avoid more undefined behavior
- I think the page got a typo on there sample code there. They probably mean
- Mixing Semicolon/Comma/Newline Separators for Blocks
- I was surprised to hear they allow mixing separators in the first place. Just more change to avoid ambiguity
- Sometimes we use new line to separate code that is too long, not sure if this impact that
- It really is pick your medicine. I am not bothered which way they do it as long as it is consistent and not ambiguous
- Might want to write down the result once I have project upgraded
- Unique Specifier Changes
- <unique><computes> is no longer allowed, now <unique> requires <allocates>
- <unique> – When a class is unique, you can make 2 instances with the same value and they are still not equal to each other
- I am not sure what to make of this bullet point since <computes> doesn’t seem to be a class specifier
- <allocates> is not on the specifier document yet?
- If <unique> requires <allocates>, and <allocates> is new. Why don’t just add the feature <allocates> is doing into <unique>?
- Function-Local Qualifiers
- now you can make variables as local with (local:) in case there is another variable with the same name but from outside of scope
- Personally speaking, you shouldn’t need this since you should name variable in a way that is clear and not duplicate…usually
- Are they trying to allow verse coding library? One use I can think of is allowing utility code library to be shared. Therefore, the code library will want to make sure they are using local qualifier so the project won’t mess with library if they have any global variables. I would love to have utility libraries.
- Public Fields in Structs
- Using <public> is no longer necessary
- Small and nice QoL improvement
Leave a comment