Release Notes for 465

[LuaCow]

Notes for Release 465

[Maximum_ADHD]

Client Difference Log

0.465.0.417678

API Changes

Added Property string TextBox.Content [ReadOnly]
Added Property string TextButton.Content [ReadOnly]
Added Property string TextLabel.Content [ReadOnly]

(Click here for a syntax highlighted version!)

[Dekkonot]

That’s… unexpected. Any additional info on that?

This is my favorite change. Very developer facing.

[TheCarbyneUniverse (Carbyne)]

For the new content property of text:

How will \n and \t work with this? What I mean is will it return the string with a tab character or 4 spaces (since it’s “raw”)? Normal Text property works with the characters themselves, so you can, for example, perform string.split with the separator being that escape character. I was wondering if this was different for Content.

[PeZsmistic]

Fixed incorrect decal thumbnails for grayscale with alpha images.

What was it?? This has been a problem for such a long time, I’m super curious to know what the problem was.

[sjr04 (uep)]

I think “raw” is misleading, it is actually the rendered text. The raw text would include tags and such. It does explain that is it actually what is rendered later on though.

There shouldn’t be any other problems, since \n is a newline, \\n is a literal backslash then the letter n. Same for \t

[Halalaluyafail3 (FindFirstChild)]

@Dekkonot

That’s… unexpected. Any additional info on that?

:: seems to be like as, so certain conditions can be removed from a type, for example number? can be converted to number.

--!strict
local a:number? = 1
local b:number = a::number -- ok
local c:number = a -- not ok

However, other postfix operators (.,[],(), and ::) can’t be used after ::, which makes this not allowed:

--!strict
local a:{number?}? = {1}
local n:number = a::{number?}[1]::number -- error

So a parenthesis must be added to fix it:

--!strict
local a:{number?}? = {1}
local n:number = (a::{number?})[1]::number

This means that :: can’t be used twice in a row without parenthesis

--!strict
local a:number? = 1
local b:number = a::number::number -- error

I believe this allows for goto labels using the syntax Lua 5.2+ uses to still be added, for example this is a valid program in Lua 5.4:

local function number()end
local a = 1
local b = a::number::number()

[tnavarts]

Yes, TL;DR: It’s the as operator.

For context: We would very much have liked to use as but that has some problematic syntax characteristics that would require using parenthesis in surprising places where they would seem unnecessary.

[starmaq]

I also noticed the update in the documentation of luau, mega useful thank you!

Type checking

[DataBrain (Amber)]

Yes! Type assertions are going to go a long way in making it so I don’t have to affect runtime code when working around limitations of the type system.

For example, in cases where I wanted to set an object of a non-nilable type to nil (because I knew that it would be guaranteed to exist in all other relevant places), I would have to have code something like this:

local NIL_TYPED_AS_ANY: any = nil
-- ...
local x: foo = getFoo()
-- ...
x = NIL_TYPED_AS_ANY

Now I can just do

local x: foo = nil :: any

Obviously type assertions to the any type is a code smell in 99% of scenarios, so I only use this to overcome the current limitations of the type system, knowing that in the future they are likely to be improved to the point where I don’t need type assertions.

It would be nice to have the ! operator like in typescript to assert that an object exists. For example:

local success: boolean, err: string? = pcall(function()
end)
if not success then
   print(err!)
end

Equivalent to:

local success: boolean, err: string? = pcall(function()
end)
if not success then
   print((err :: any) :: string)
end

[zeuxcg]

@DataBrain

that in the future they are likely to be improved to the point where I don’t need type assertions.

Yup - that’s the hope. The nice thing is that :: is pretty distinctive and very easy to search for, so it’s quick to find all the assertions and see if you don’t need some of them anymore. :: can also help on the boundary between non-strict and strict code.

The request for ! is noted. We are doing a lot of work on refinements right now so there’s a large class of cases where the type checker today doesn’t correctly model nilability and will do it right in a few weeks, but indeed the case you’ve brought up is challenging to get right without explicit assertions.