Any plans on adding Design By Contract type features other than null checking.  It is quite cumbersome in most languages to check for preconditions (postconditions, invariants) and then copy the precondition text into the function doc and then finally write a unit test to exercise the precondition check.

For example:

/** does it.
     @param i cannot be < 0 or > 100.
     @return will never be less than zero
*/
int doIt(Int i) 

Instead I'd like to be able to write (maybe this isn't the best syntax but you get the idea). The conditions would be part of the method signature and therefore they don't have to be doc'd or tested (unless you want to make sure they don't change).

/** does it. */ 
int (< 0) doIt(int (< 0 || > 100) i) 

aside from reducing boilerplate docs, tests, etc. It would be cool if the compiler could check these constraints at compile time.  I'm thinking something similar to what microsoft is doing with specsharp & code contracts

Typo: "ClassCastException is the object" should be "ClassCastException if the object"

How are static non-null class fields ensured when running code from inside field intializers? Does nonnull provide a hard constraint within the context of the ordering of initializers.

Does this mean that fields that need to be initialized in the constructor can't be nonnull ?

Any chance of a 'assign once' modifier for variables ?

Looks very much like Nice which also assumes any Java code may return null unless you tell it otherwise by defining a more refined type signature for the import.

How do you solve the null-safety with collections?

Question 1:

How do arrays get instantiated and initialized?

A normal array with not nullable items:

An array which can contain null-references may look like this:

Or a nulllable array which can contain null-references:

If the items must not be null, how do you initialize an array in a loop?

Maybe one can specify a default value for initialization:

Or a function for initialization:

Or does there exist a special construct for initialization of collections?

Question 2:

What's with a generic dictionary? How does the developer of the dictionary specify, that the key must not be null? Or must null explicitly be allowed?

Best regards,
JMP

Tipo: The link under "What's next" should probably be "Expressions", not "Exceptions".

iu--

Maybe add "?" as a postfix-operator also, so that you can write:

instead of

1. What is the difference between "a?.b()" and "a?b()"? If it means the same: the first one is nicer to look at, but what can you do to make as easily typed as the second one in the IDE?
2. What about a shorter syntax for "if (a != null) ...", maybe "if (a?) ..."?

re: npe().  Wow, you are really rubbing it in Java's face.  A function to recreate the least popular error of all times, so code can break at runtime instead of compile time.  I admire your brazenness.  

Is System.out nullable? That is just ... sad.

Any likelihood to special case idioms like this from the JDK? Although one could technically set out & err to null, it would be obscure. Were I reviewing "System.setOut(null)" in a fellow's code, I'd call them out on it.

I would add 4th item to the list of possible NPE sources:  Multithreading done wrong. At least, this might be a remark to 3rd point.

Possible example:

Are nullable types somehow retained in bytecode? Is there a way to introspect the nullability of a property using reflection? Maybe the compiler could implicitly add some specific annotation to such properties? This could be useful in ORMs which could emit NOT_NULL statements in DDL automatically.

I have yet another question about null-safe design approach. Sorry if you've already covered it elsewhere.

In Scala, Options (thus nullable types) are treated pretty much like collections: for non-null value we have a one-element collection; or we get Nil otherwise. This approach brings a couple of techniques I currently can't imagine my life without:

• using monadic functions on nullable types, as you normally do with collections: 
• returning values in flatMap, when working with collections:

Now I can't imagine all such small code fragments implemented with IF-statements and elvis operators. So, how such things will be going in Kotlin?

I found myself in situation like this:

Here T possibly can be nullable and T? is always nullable. How can I make NPE to be thrown only if T is not nullable and event value is null?

I mean somethig like this:

upd: I've found solution for this particular case

but there is still no way to call method with generic parameter with surely nullable argument and have npe only if argument is null and generic parameter is not nullable

How do you recommend dealing with external libraries, where Kotlin typically assumes that they are returning a value that might be null, whereas in reality they will never return null?

For example, in the Google Guava libraries, BloomFilter.create(..) always returns a BloomFilter, but Kotlin assumes that it could be null, even though this will never happen.

Should I just use the !! operator on the value returned by the function, or is there a better way to deal with this?

I'm new to Kotlin, but I really like its null-safety features with the various uses of '?'. It's all very consistent and elegant.

But here's a suggestion: the only place where you don't use the ? symbol is in the keyword null itself. This is inconsistent (and seems old-fashioned, like the ugly days of C++) - and of course null hardly ever needs to be mentioned in code anyway.

So: why not simply use the symbol ? itself:

You could always deprecate null for the moment & remove it later.

If this is possible, I would love Kotlin.

Hi,

Any reason why two '!'  in : 

why not a single '!':

is it just a preference or there is a explanation behind it ?