On Saturday, 20 February 2016 at 09:40:40 UTC, Tobias Müller wrote:
> ...
> It's not much more verbose but more explicit.
> Changing the type of a variable based on static analysis is just advanced
> obfuscation. It hurts readability and the gain is questionable. At least it
> only works for nullable types.

I consider this feature similar to requiring all control paths to initialize a variable or return a value. Imagine requiring some explicit or verbose syntax to enforce this behavior. I don't see this being an issue as long as the behavior is consistent between compilers (if code works in one compiler, it works in all compilers).

On 2016-02-19 13:28, Nemanja Boric wrote:

> IMHO, without language support looks really bad - `map` really sticks
> out here.
>
> What Rust is doing:
>
> ```
> let foo: Option<i32> = bar();
>
> let new_stuff = match foo {
>     Some(x) => x,
>     None => 0
> }
> ```

You can do the same in Scala, it has built-in pattern matching. Although I think the map approach is preferred, but I'm not a Scala expert.

-- 
/Jacob Carlborg

On Thursday, 18 February 2016 at 23:33:45 UTC, Yuxuan Shui wrote:
> Just come across Kotlin today, and found some interesting ideas skimming through its tutorial:
>
> [...]

Both those issues predate both Kotlin and Swift. C# has had both of them for as long as I've been coding in the language. Nothing new here.

On Monday, 22 February 2016 at 19:33:12 UTC, Ice Create Man wrote:
> On Thursday, 18 February 2016 at 23:33:45 UTC, Yuxuan Shui wrote:
>> Just come across Kotlin today, and found some interesting ideas skimming through its tutorial:
>>
>> [...]
>
> Both those issues predate both Kotlin and Swift. C# has had both of them for as long as I've been coding in the language. Nothing new here.

Sure that Optional types and dynamic casts have been there for ages. But this is the first time I see a compiler does the unwrapping & casting for you based on static analyses.

And Xinok pointed out we have been using the same technique for detecting uninitialized variables, so what Kotlin does can be seen as a small, but clever, extension of this.

On Mon, 2016-02-22 at 19:33 +0000, Ice Create Man via Digitalmars-d wrote:
> On Thursday, 18 February 2016 at 23:33:45 UTC, Yuxuan Shui wrote:
> > Just come across Kotlin today, and found some interesting ideas skimming through its tutorial:
> > 
> > [...]
> 
> Both those issues predate both Kotlin and Swift. C# has had both of them for as long as I've been coding in the language. Nothing new here.

But lots of what Kotlin, and Ceylon, are doing are new… on the JVM. I
like new, I like progress and evolution. Just because an idea is not
objectively new, doesn't mean it isn't new and useful. Context and
application can be as refreshing as having a brand new idea. Just think
in programming languages today actors, dataflow, CSP are new, despite
being 50-ish, and 40-ish years old.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

rsw0x <anonymous@anonymous.com> wrote:
> On Saturday, 20 February 2016 at 09:40:40 UTC, Tobias Müller wrote:
>> Yuxuan Shui <yshuiv7@gmail.com> wrote:
>>> [...]
>> 
>> In Rust that would be:
>> 
>> let var : Option<i32> = ...;
>> if let Some(var) = var {
>> // You can use var here
>> }
>> 
>> It works for every enum (= tagged union), not just Option<T>
>> 
>> Swift also has "if let".
>> 
>> It's not much more verbose but more explicit.
>> Changing the type of a variable based on static analysis is
>> just advanced
>> obfuscation. It hurts readability and the gain is questionable.
>> At least it
>> only works for nullable types.
>> 
>> Tobi
> 
> D has this too, but only for nullable types afaik.
> 
> if(byte* ptr = someFunc()){
> //...
> }
> 
> 

That's not quite the same as there are no non-nullable pointers in D.
There's no guarantee from the type system that the byte* is not null and
there are no compiler checks involved.
It's a simple runtime check.

OTOH in the examples in Kotlin/Rust the variable 'var' changes its type
from 'int?' to plain 'int'.
In Kotlin this is done with static analysis, in Rust with rebinding of the
name.

Tobi

On Tuesday, 23 February 2016 at 06:49:46 UTC, Tobias Müller wrote:
> rsw0x <anonymous@anonymous.com> wrote:
>> On Saturday, 20 February 2016 at 09:40:40 UTC, Tobias Müller wrote:
>>> [...]
>> 
>> D has this too, but only for nullable types afaik.
>> 
>> if(byte* ptr = someFunc()){
>> //...
>> }
>> 
>> 
>
> That's not quite the same as there are no non-nullable pointers in D.
> There's no guarantee from the type system that the byte* is not null and
> there are no compiler checks involved.
> It's a simple runtime check.
>
> OTOH in the examples in Kotlin/Rust the variable 'var' changes its type
> from 'int?' to plain 'int'.
> In Kotlin this is done with static analysis, in Rust with rebinding of the
> name.
>
> Tobi

Rust's Option<T> checks are not done at compile-time in most cases unless something changed drastically in the past ~18 months.

On Tuesday, 23 February 2016 at 07:18:09 UTC, rsw0x wrote:
> On Tuesday, 23 February 2016 at 06:49:46 UTC, Tobias Müller wrote:
>> OTOH in the examples in Kotlin/Rust the variable 'var' changes its type
>> from 'int?' to plain 'int'.
>> In Kotlin this is done with static analysis, in Rust with rebinding of the
>> name.
>>
>> Tobi
>
> Rust's Option<T> checks are not done at compile-time in most cases unless something changed drastically in the past ~18 months.

Option<T> is an enum type in Rust (i.e. algebraic data type). The Rust compiler forces you to check all possible cases so you can't use it improperly. So you would have to use something like pattern matching or "if let" to check the state.

https://doc.rust-lang.org/book/match.html#matching-on-enums

On Tuesday, 23 February 2016 at 14:58:21 UTC, Xinok wrote:
> On Tuesday, 23 February 2016 at 07:18:09 UTC, rsw0x wrote:
>> On Tuesday, 23 February 2016 at 06:49:46 UTC, Tobias Müller wrote:
>>> OTOH in the examples in Kotlin/Rust the variable 'var' changes its type
>>> from 'int?' to plain 'int'.
>>> In Kotlin this is done with static analysis, in Rust with rebinding of the
>>> name.
>>>
>>> Tobi
>>
>> Rust's Option<T> checks are not done at compile-time in most cases unless something changed drastically in the past ~18 months.
>
> Option<T> is an enum type in Rust (i.e. algebraic data type). The Rust compiler forces you to check all possible cases so you can't use it improperly. So you would have to use something like pattern matching or "if let" to check the state.
>
> https://doc.rust-lang.org/book/match.html#matching-on-enums

How does this differ from the example I gave where the branch is only taken if the pointer is non-null?

On Tuesday, 23 February 2016 at 19:43:43 UTC, rsw0x wrote:
> ...
> How does this differ from the example I gave where the branch is only taken if the pointer is non-null?

D doesn't prevent you from dereferencing a null pointer whereas these scenarios should be impossible in Kotlin as well as Rust. Case and point, this code compiles without issue but crashes at runtime:

    int* foo()
    {
        return null;
    }

    void main()
    {
        if(int* ptr = new int)
        {
            ptr = foo();  // Whoops...
            *ptr = 35;    // Crash
        }
    }

In D, pointers and reference types can spontaneously become null under almost any context. That's the difference.