Which programming languages support type inference from variable names?By 'type inference', I mean, for example, in Swift, how if you let x = 39 then the compiler knows x is an Integer, because 39 is an integer. Now, it's conventional in Swift to use the keyword is at the beginning of Boolean variables. For example let isCool = true. However if we do let isCool = 0, the compiler will infer the type of isCool to be Integer instead of Bool, even though any human programmer would know it was supposed to be a Bool due to the presence of is at the beginning of the variable name.So, it occurred to me, I wonder if there are any programming languages where you can give the compiler a clue to help it infer the type by using keywords in the variable name itself? Has anyone ever seen something like that?Side note:This was not intended to be a question about the merits of doing this, but just so you know, the reason I asked it was because I thought it is something that could be a feature that might allow for cleaner code in webservice integration layers, due to the necessity of parsing a lot of JSON into variables and languages like Swift making this a pain with all their enforced type safety. So here is an example of how this might improve some code in Swift.Suppose customersJSON is some data that came from a webservice response. If the server has a bug then the contents might not be the types we expect. So a strictly type safe language like Swift 3 currently enforces code that looks like the following:    let customersJSON = [{\customerName\:\Alice\,\customerAge\:42},{\customerName\:808,\customerAge\:88}].data(using: .utf8)!    var customersArray: [Any]!    do {        customersArray = try JSONSerialization.jsonObject(with: customersJSON, options: JSONSerialization.ReadingOptions()) as? Array    }     catch {        print(error)        return;    }    for customer in customersArray {        guard let customerDict = customer as? [String:Any],            let customerName = customerDict[customerName] as? String,            let customerAge = customerDict[customerAge] as? Int             else {break}        print(customerName: \(customerName), customerAge: \(customerAge))     }Note that when we assign dict[customerName] to customerName, we have to tell the compiler that customerName should be a String with the syntax as? String. Of course, human beings know that names are always strings; as a programmer it's just annoying to me to always have to tell the compiler this, if for example, I have several different things like productName and itemName and discountName etc. that must be handled in various response handlers. I'd much rather tell the compiler one single time that any variable whose name ends in Name is a String.I'd much rather set a global preference in my app, using regex matching patterns to give the compiler a heads up, like: Infer .*Array:[Any]!Infer .*Name:StringInfer .*Age:IntInfer .*Dict:[String:Any]Then we can do:    let customersJSON = [{\customerName\:\Alice\,\customerAge\:42},{\customerName\:808,\customerAge\:88}].data(using: .utf8)!    var customersArray    do {        customersArray = try JSONSerialization.jsonObject(with: customersJSON, options: JSONSerialization.ReadingOptions())    }     catch {        print(error)        return;    }    for customer in customersArray {        guard let customerDict = customer,            let customerName = customerDict[customerName],            let customerAge = customerDict[customerAge]             else {break}        print(customerName: \(customerName), customerAge: \(customerAge))     }... and still have total type safety of Swift, without all the ugliness. Now it looks more like a dynamically typed language's code. I'm not saying it's better this way, but I do think it makes for more elegant, more readable code. YMMV
Which programming languages support type inference from variable names?
compiler;type
Very early versions of FORTRAN used the first letter of the variable name to denote the type, for basic types INTEGER and REAL.  Double precision (extended-precision reals) had to be declared explicitly.As of at least FORTRAN IV, at least some versions of FORTRAN allowed explicit declarations to override the first-letter rule.FORTRAN 77 allowed one to specify one's own personal first-letter rules, and to disable them altogether.  (Example: IMPLICIT INTEGER(NONE))It should be mentioned that it was generally accepted in the computing community by at least the mid-1960s that default type rules and implicit variable declarations were a very bad idea.  Tony Hoare reports having his ears soundly boxed by the ALGOL Committee when he proposed such modification to ALGOL.  (He mentioned that this was before the probably-apocryphal story of the lost Venus probe, due to a typographical error that nevertheless yielded a syntactically-legal FORTRAN program, became widely known.)