Talk:Type safety

message: I came to this page trying to find out about Type Safety. I read in the first paragraph that there are different definition of the term, but I'm not told what any of them are. I keep reading but I still don't find out what Type Safety is.
So I looked in the Definitions thinking I'd find some clues. But the definition starts with a nice little quote which doesn't really tell me (and, by the way, is obviously not true). So I keep reading and find that there are definitions in there, but definitions for Type Safety. Even a definition of 'Type' would be good, but alas no.
I'm reading the article because I want a quick understanding of what Type Safety is. What is a Type? What is Type Safety. I can't find anything in the article that gives me a quick overview so I can decide which bits I want to carry on reading.
The definition of Type Safety on the article "Strongly-typed programming language" is much clearer than the content of this article. A cleanup is definitely required
: What you say is true.  The problem is that there is no generally agreed definition of the term, or even set of properties a program may have to be considered type safe.  For instance, see the discussion on garbage collection below.  The article is written from an idealised theoretical point of view (which is a clue to the fact that the safe in type safe does not have a lot to do with real life safety, although I'm sure the theoretical people will disagree). Derek farn
:: Thanks for the feedback. Without trying to create a 'perfect' definition of what Type Safety is, would it be possible to provide a loose definition. For example, is it possible to list the features of Type Safety that all definitions agree on? And then go on to list the differences between the definitions. Something along the lines -- "Some definitions of Type Safety include a).. b)... c)... , whereas others consider that only d)... and e)... are really required for Type Safety". -- In this way there won't be the problem of trying to create a definition that everyone agrees on because, as you say, this may not be possible. But at least I would be able to get a simple idea up-front that would make me think "ah-ha I see what the article is about now, I can decide whether I need to read any more or not". If that woudl be possible I think it would go a long way towards helping the article.
"The formal type-theoretic definition of type safety is considerably stronger than what is understood by most programmers." Who counted how many programmers understand type safety and in what way? This phrase communicates no new or even interesting information, beside being judgmental. Reword or remove? It seem to imply that there is a common confusion (needs not to state the percentage of programmers who are confused, enough two programmers to share the confusion for the confusion to be common) that type safety is an attribute of the environment executing the program than the language (which is basically what was said in the preceding sentence.)  — Preceding unsigned comment added by 109.65.38.7 (talk) 11:27, 28 April 2012 (UTC)
thread_title: Cleanup Required

message: This article is full of highly questionable claims (Java and Scheme have been "mathematically proven" to be type-safe? Type safety requires a garbage collector?). There isn't even any mention of the key concepts in type-safety, viz. type-preservation and progress! I encourage editors to read the illuminating discussion on this very topic on the TYPES list. The present article only exposes a needless confusion of semantics  (types) and implementation details (gc, etc.). — Kaustuv 20:06, 2004 Aug 17 (UTC)
:Note, in it's present state the article discusses preservation and progress, near the very top of the article. Other readers should also see the conversation with Kaustuv and myself below that explains why GC is more than just an implementation detail. (To be fair, I would call it a technical detail, in the same way that, in a mathematical proof, division by zero is a "technical detail" that can be significant enough to make the proof invalid.) --MShonle 02:34, 8 January 2006 (UTC)
thread_title: Questionable claims

message: I originally just wanted to add the link to Wright and Felleisen, who are generally credited with having invented Preservation and Progress.  I ended up creating a new Definitions section, and became worried about the fact that the article defined type soundness in such a way as to completely rule out denotationally-specified languages (they have nothing analogous to Progress).  W&F's paper describes some of the denotational-semantics-based notions of safety that were around before they did their thing; it seems like as long as this article is going to mention formal stuff we should at least leave room for someone who knows about denotational semantics to put in a word or two, so I tried to do that.
I have also clarified a bit how a dynamically-typed language can be type safe.
Another thing I think this article should say but doesn't is: Only in a type-safe language are type annotations really meaningful.  In C, you can declare a local variable 
: struct something *x;
but, because C is not type-safe you can never be sure that x points to a legitimate something unless you have just created it yourself.  In Java, on the other hand, if you say
: Something x;</code>
then anything that might result in x being anything other than an instance of Something (or of one of its subclasses) will be illegal.
And since Ph.D. students in programming languages seem to be playing a big role in this discussion, I'll mention that I am one too.  :-)
Cjoev 00:04, 24 January 2006 (UTC)
thread_title:  New "Definitions" section 

message: I just reverted a major edit that removed large amounts of content with insufficient explanation: the worst of these was the deletion of the entire section on memory management on the basis that "garbage collection has nothing to do with type safety", a subject that has already been argued extensively on this page.  Other deletions included Robin Milner's famous slogan, the nod to denotational semantics and a slightly philosophical discussion of the meaning of "unsafe".  Cjoev 21:55, 22 September 2006 (UTC)
thread_title:  Reverted deletions 

message: The "citation needed" claim that Java and Standard ML have type safety proofs is false. There is no type safety proof for any language officially recognized as Java. A type safety proof for a language that is a small delta from SML97 is ongoing (nearly complete, from what I know) work at CMU.
:There is no type safety proof for Java because Java is not typesafe: see .
:On the other hand, this hole in the type system requires the use of multiple class loaders, so could be considered to be an unusual position for developers to get into. Under most circumstances Java is type safe. I might suggest that the article retains the claim that this is so, with a reference to this paper. JoeKearney 09:58, 1 June 2007 (UTC)
replies: text: As noted above, Java (the language) most certainly is type-safe. Bugs in specific implementations of the Java Virtual Machine (which the Saraswat paper demonstrates) are a completely separate issue.  However, to my knowledge, there never has been a formal proof that Java is type-safe (which, given the complexity of virtually all non-toy languages, is commonplace). That is, we shouldn't care that Java hasn't been mathematically proved to be type-safe, as virtually all common program languages haven't either. It's enough to state that Java is type-safe by design, which is all we really care about in this article.  trims2u 21:43, 19 June 2011 (UTC)
replies: text:  The Saraswat paper purports to demonstrate a type-safety issue not in a specific implementation of the JVM, but in the JVM spec itself. If you wish to assert otherwise, please provide a reference. (Also, the current text implies that the issue no longer exists. If true — and I well believe it — then it should have a reference as well.) —RuakhTALK 14:36, 21 June 2011 (UTC)
replies: text:  Sarawat provides a potential issue in the original Java Specification, which results in a possible vulnerability in a JVM implementing the early Java VM Specification.  Sarawat's bug was addressed in the Java 1.2 specification, and all VMs implementing that specification or later do not exhibit the flaw. Later discussions have found a couple of other class-loading issues, which have been subsequently fixed.  All that said, the design of Java is to be type-safe; like all other software in this world, bugs may compromise this goal. Trims2u (talk) 10:05, 30 January 2012 (UTC)
thread_title:  Java and Standard ML do not have type safety proofs 

message: I'd like to add some general or introductory information to the article regarding the interpretation of type safety based on context. In my experience there are degrees of type safety, from "terrible" - such as in assembly, where it is typically impossible for the compiler to track any type information at all - to C, where at the least, the compiler issues a warning during implicit conversion of types to verify programmer intent, to certain situations in C++ where use of reinterpret_cast is required to verify programmer intent. It's true that none of these situations are "strictly type-safe", but I feel they should be included for informational purposes. Reinderientalk/contribs 20:52, 8 August 2008 (UTC)
thread_title:  Degrees or interpretations of type safety 

message: Does this strike anyone else as contradictory, or am I misunderstanding something?
"Type safety is a property of the programming language, not of the programs themselves. For example, it is possible to write a safe program in a type-unsafe language."
If it isn't a property of the program, how can it be possible to write a type-safe program?  —Preceding unsigned comment added by 96.242.156.9 (talk) 00:53, 5 October 2008 (UTC)
replies: text: Yes, it seems contradictory to me too.--151.202.239.74 (talk) 20:09, 29 July 2009 (UTC)

text: You have to look at the missing words: He speaks about writing a save program and not about not a type-save program. The typical weasel argument of an advocate of type-unsafe languages. And it is true - you just have to do all the safety services which a type-save language provides yourself. Only a human never does it as reliably as the automated process of a programming language. --Krischik T 16:21, 10 August 2009 (UTC)

text: yes,  it sounds contradictory. Maybe he is not speaking about a type-save program, but the "For example..." words don't leads to that conclusion.  —Preceding unsigned comment added by 79.154.168.94 (talk) 08:44, 2 December 2009 (UTC)

text: No, it is not contradictory. Type safety is a property of languages. It might be possible to write type-correct programs in type-unsafe languages, but it is not possible to write type-incorrect programs in type-safe languages. This is what type safety is about. Eduardo León (talk) 15:08, 27 June 2013 (UTC)
thread_title:  Contradictory? 

message: The notion of "type safety" in the so-called "dynamically typed" (really, unityped) languages is meaningless. Type safety is all about preventing failures. It must be remarked that all incorrect type coercions result in program failures - it is just that some unityped languages make these failures more evident (e.g., Python) while others attempt to disguise these failures as weird forms of "success" (e.g., JavaScript). Eduardo León (talk) 15:15, 27 June 2013 (UTC)
thread_title:  Type safety and "strong typing" 

message: This is a placeholder for a 'discuss' tag. I look forward to this discussion. My citation stems from Peyton-Jones' explanation of the GHC Core. My plan is to annotate my contribution with timestamps into the video clip.YouTube: Into the core - squeezing Haskell into 9 constructors, by Simon Peyton-Jones (14 Sep 2016), Erlang Conference --Ancheta Wis    (talk  | contribs) 18:06, 14 December 2017 (UTC)
thread_title: Type safety of System F