@darksnake I don’t think the approach with non-nullable front will work. It will throw exception in any case when nullable is null which is not what is needed if the generic type parameter is a nullable one.
If you think you can plan architecture in a more clear way, please check my related question on StackOverflow I have posted a moment before I have got the answer here. It has a clear requirement for MutableOptional class (the example I have started this topic with is a bit confusing, MutableOptional is much more understandable for people). Feel free to post your version of implementing such class.
In this case you need explicit cast (though I am not sure that you need to suppress warning). But when I am talking about architecture, I propose to think of whether you need such class in the first place.
In Swift you have the concept of a recursive optional (an optional of an optional). That would neatly solve the issue I think.
class Foo<T> {
value: T? = null // If T is an optional type (say Bar?), this would actually be an optional of an optional: Optional<Optional<Bar>> or Bar??
}