That’s a good observation because Instance:Clone() actually does return nil if Instance.Archivable is false. Despite this, the same warning occurs even if Instance.Archivable is certain to be true.
SpecialScript is declared without type notation, so it doesn’t have any “locked” assigned type (although it’s nil) until something is assigned. I assume what bothers the type inference system is that SpecialScript may either be nil or ModuleScript after the loop.
Considering this example:
--!strict
local function TakeAChance(): string
local outcome --: string?
if 1 == 2 then
outcome = nil -- whichever type
end
if not outcome then
outcome = math.random(0,1) == 0 and "heads" or "tails"
end
return outcome
end
Clone doesn’t return Instance, it returns the same type that it’s called with.
The type checker is far from perfect but check the types you have on your SpecialScript and Template.
Yeah, this issue is very similar to this simplified example:
--!strict
local function GiveMeAName(part: Part, name: string?): string
name = name or "Jeff"
part.Name = name --> name underlined, type is clearly a string
end
Because there’s a possibility there may be no name argument, type checker doesn’t (yet) see that name cannot be anything but a string when assigned.
After the temporary variable is created, it’s type is assigned once it starts pointing to the cloned module. SpecialScript is still subject to warnings because the type system deems it possibly nil.
Another solution is to reasure the type checker that SpecialScript will definitely exist.