The disadvantage is that as currently already means something that is entirely different. How would you propose to spell the feature that’s currently spelled as?
It's not standardized by the language. Maybe by the Swift Standard Library, but users use all sorts of different ways to convert between types. Initializer, computed properties, functions.
The standard library is a part of the language itself. Users can name things how they want, but there is a clear standard.
It already means more than one thing under the hood with the same end result. After you call the as operator passing a different type, you'll get that different type. There's no mental friction in reusing it for this purpose.
As Operator Overload, as the name of the topic.
Correct me if I'm wrong, but currently every usage of as will have an extremely inexpensive operation cost.
Allowing it's use as a generic conversion operator will inevitably result in much more expensive operations.
As I said originally. I thinking changing what as means is a bad idea, but I do personally prefer the cleaner syntax so could be in favor of something else that accomplishes this.
Fair enough, people would still be able to keep using initializer, computed properties and functions to convert between types, but having a language construct to do it has its advantages. For starters the standard is implicit. As far as I know, there's no official documentation stating that an initializer with no label is the standard. One would have to learn this with experience like I did. OK, we can just add that to the documentation, but I still think reusing the as operator is clearer than an initializer since an initializer can mean other things as I mentioned. OK, the as operator, under the hood, also has different mechanisms, but the end result would be the same for every case, toll-free-bridging, subtype relationships, and type conversion. You apply the operator with the type you want when you get a value with that type.
What do you mean exactly?
So your argument is that the current initializer syntax is not good because it can have meanings other than conversion, but overloading the as operator with additional meanings is better?
The API Design Guidelines are probably the closest to this. But regardless, the language is still settling and the Official Style Guide is just getting going.
I'm saying the meaning is the same. You ask for the as operator to give you another value with the other type you specified based on the current value. The "how" might be different, but the "what" that the operator is doing is the same for every case.
e.g. someone could implement func as(data: Data) -> File that saves the passed data to a file.
This is a circular argument. If you change the language so that as can be sugar for any function (T) -> U, then as can work that way. The question is, why do you think that is better than an initializer, and how would users get back the current functionality? What you propose is certainly not the same as the current meaning of as.
Is it really that strange to read:
someValue as SomeType
as:
"Hey compiler give me this value but with this other type"
?
What's your main issue with this proposal? The reuse of the as operator or a language construct to state the mapping operation?
My issue is exactly as stated:
That's what's happening currently. that is not what would happen if you allow general usage of as to convert between Types.
With Bridging, you have two way, Value-level equality. AFAIK there's no way to generically guarantee this will be the case for a user's implementation.
Well, I already explained it. It's best to have a language construct that serves only this purpose. The mapping between types. As I see it, the as operator is the one that does it. I don't think you see it that way, and I think that's why you're having issues with using the as operator, correct me if I'm wrong. That's why I asked if you had issues with reusing the as operator. Now, let's say we use another operator like @GetSwifty mentioned. Let's call it map. Your use of (T) -> U just made me realize that it is simply a map operator. For the sake of the argument, forget about potential clashing issues with the existing map functions. What do you think about:
let string: String = "Hello world!"
let nsstring = string map NSString
Or we could even use mapto and not worry that much about clashes:
let string: String = "Hello world!"
let nsstring = string mapto NSString
Or simply to like @GetSwifty (great username, by the way 
) proposed:
let string: String = "Hello world!"
let nsstring = string to NSString
What do you think? You still prefer initializers?
Didn't understand this part.
So you mean when you use the as operator there's a hidden assumption that the memory layout would be the same? Is this true for subtyping relationships? Is this assumption in widespread use by the community, assuming it is correct?
Thanks! 
As far as the bridging with Objective-C, I don't know if the memory is identical bit-by-bit, but my understanding is a lot of engineering went into the bridging being as inexpensive as possible.
For down-casting, I believe the only actual difference is your compile-time interface and it has no effect at all on the value. E.g in a UITableViewController subclass:
let testSelf = self as UITableViewController
Results in testSelf having the same memory address as self. It's possible the cast isn't even visible once you get into assembly, but that's not something I know much about.
Sorry, but I don't get the argument that introducing a very limited new operator (that would serve a single purpose that can easily be done today) add clarity and simplify the language.
First, user would have to learn it, its usage, and inevitable limitations. Then we will perpetually have to justify its existence and why it should be use instead of simply using a function or an initialiser to perform the very same task.