December 04, 2019
On Tuesday, 3 December 2019 at 23:44:59 UTC, mipri wrote:
> Option 4: typeof(return)

typeof(return) is super cool for like option type things too!
December 03, 2019
On Wed, Dec 04, 2019 at 01:01:04AM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote:
> On Tuesday, 3 December 2019 at 23:44:59 UTC, mipri wrote:
> > Option 4: typeof(return)
> 
> typeof(return) is super cool for like option type things too!

typeof(return) is one of the lesser known cool things about D that make it so cool.  Somebody should write an article about it to raise awareness of it. :-D


T

-- 
An imaginary friend squared is a real enemy.
December 04, 2019
On Wednesday, 4 December 2019 at 01:28:00 UTC, H. S. Teoh wrote:
> typeof(return) is one of the lesser known cool things about D that make it so cool.  Somebody should write an article about it to raise awareness of it. :-D

you know i probably will write about that next week. so be sure to like, comment, and subscribe so you never miss my next post and then give me all your money on patreon so i can keep bringing you content :P :P
December 04, 2019
On Tuesday, 3 December 2019 at 23:44:59 UTC, mipri wrote:
> On Tuesday, 3 December 2019 at 10:13:30 UTC, mipri wrote:
>> Speaking of nice stuff and aliases, suppose you want to
>> return a nice tuple with named elements?
>>
>> Option 1: auto
>>
>>   auto option1() {
>>       return tuple!(int, "apples", int, "oranges")(1, 2);
>>   }
>>
>> Option 2: redundancy
>>
>>   Tuple!(int, "apples", int, "oranges") option2() {
>>       return tuple!(int, "apples", int, "oranges")(1, 2);
>>   }
>>
>> Option 3: an alias
>>
>>   alias BadMath = Tuple!(int, "apples", int, "oranges");
>>
>>   BadMath option3() {
>>       return BadMath(1, 2);
>>   }
>
> Option 4: typeof(return)
>
>   Tuple!(int, "apples", int, "oranges") option4() {
>       return typeof(return)(1, 2);
>   }

aha nice
December 04, 2019
On Tuesday, 3 December 2019 at 10:19:02 UTC, Jonathan M Davis wrote:
> On Tuesday, December 3, 2019 3:03:22 AM MST Basile B. via Digitalmars-d- learn wrote:
>> On Tuesday, 3 December 2019 at 09:58:36 UTC, Jonathan M Davis
>>
>> wrote:
>> > On Tuesday, December 3, 2019 12:12:18 AM MST Basile B. via
>> >
>> > Digitalmars-d- learn wrote:
>> >> I wish something like this was possible, until I change the return type of `alwaysReturnNull` from `void*` to `auto`.
>> >>
>> >>
>> >> ---
>> >> class A {}
>> >> class B {}
>> >>
>> >> auto alwaysReturnNull() // void*, don't compile
>> >> {
>> >>
>> >>      writeln();
>> >>      return null;
>> >>
>> >> }
>> >>
>> >> A testA()
>> >> {
>> >>
>> >>      return alwaysReturnNull();
>> >>
>> >> }
>> >>
>> >> B testB()
>> >> {
>> >>
>> >>      return alwaysReturnNull();
>> >>
>> >> }
>> >>
>> >> void main()
>> >> {
>> >>
>> >>      assert( testA() is null );
>> >>      assert( testB() is null );
>> >>
>> >> }
>> >> ---
>> >>
>> >> OMG, isn't it nice that this works ?
>> >>
>> >> I think that this illustrates an non intuitive behavior of auto
>> >> return types.
>> >> One would rather expect auto to work depending on the inner
>> >> return type.
>> >
>> > The void* version doesn't work, because void* doesn't implicitly convert to a class type. It has nothing to do with null. auto works thanks to the fact that typeof(null) was added to the language a while back, and since class references can be null, typeof(null) implicitly converts to the class type. Before typeof(null) was added to the language, null by itself had no type, since it's just a literal representing the null value for any pointer or class reference. The result was that using null in generic code or with auto could run into issues. typeof(null) was added to solve those problems.
>> >
>> > - Jonathan M Davis
>>
>> That's interesting details of D developement. Since you reply to the first message I think you have not followed but in the last reply I told that maybe we should be able to name the type of null. I think this relates to TBottom too a bit.
>
> There isn't much point in giving the type of null an explicit name given that it doesn't come up very often, and typeof(null) is quite explicit about what the type is. Also, anyone doing much generic programming in D is going to be well versed in typeof. They might not know about typeof(null) explicitly, but they should recognize what it means when they see it, and if someone were trying to get the type of null, it would be the obvious thing to try anyway. And typeof(null) isn't even the prime case where typeof gets used on something other than an object. From what I've seen, typeof(return) gets used far more.
>
> As for TBottom, while the DIP does give it a relationship to null, they're still separate things, and giving typeof(null) a name wouldn't affect TBottom at all.
>
> - Jonathan M Davis

I think that any internal compiler types that are also things in code should be named.
Things like tuples are really a thing in the compiler (TupleExp, TypeTuple, also Tuple in dtemplate.d, ...), we still need a library type for tuples while everything there in the compiler.
December 04, 2019
On Wednesday, 4 December 2019 at 03:17:27 UTC, Adam D. Ruppe wrote:
> On Wednesday, 4 December 2019 at 01:28:00 UTC, H. S. Teoh wrote:
>> typeof(return) is one of the lesser known cool things about D that make it so cool.  Somebody should write an article about it to raise awareness of it. :-D
>
> you know i probably will write about that next week. so be sure to like, comment, and subscribe so you never miss my next post and then give me all your money on patreon so i can keep bringing you content :P :P

I've just made the refact using typeof(null) and gained 78 SLOC
The pattern was:

    void issueError();

and then in the code, in a dozen a function returning different classes types

   if (...) {
        issueError();
        return null;
   }

now this becomes:

   typeof(null) issueError();

   if (...)
        return issueError();

I wish I knew that trick before. I prefer typeof(null) in case I would translate to another language. I tend to type the static type when I know it anyway.
December 06, 2019
On Wednesday, 4 December 2019 at 12:54:34 UTC, Basile B. wrote:
> On Wednesday, 4 December 2019 at 03:17:27 UTC, Adam D. Ruppe wrote:
>> On Wednesday, 4 December 2019 at 01:28:00 UTC, H. S. Teoh wrote:
>>> typeof(return) is one of the lesser known cool things about D that make it so cool.  Somebody should write an article about it to raise awareness of it. :-D
>>
>> you know i probably will write about that next week. so be sure to like, comment, and subscribe so you never miss my next post and then give me all your money on patreon so i can keep bringing you content :P :P
>
> I've just made the refact using typeof(null) and gained 78 SLOC
> The pattern was:
>
>     void issueError();
>
> and then in the code, in a dozen a function returning different classes types
>
>    if (...) {
>         issueError();
>         return null;
>    }
>
> now this becomes:
>
>    typeof(null) issueError();
>
>    if (...)
>         return issueError();
>
> I wish I knew that trick before. I prefer typeof(null) in case I would translate to another language. I tend to type the static type when I know it anyway.

more -520 lines today.
December 06, 2019
On Tuesday, 3 December 2019 at 10:06:22 UTC, Mike Parker wrote:
> On Tuesday, 3 December 2019 at 10:03:22 UTC, Basile B. wrote:
>
>>
>> That's interesting details of D developement. Since you reply to the first message I think you have not followed but in the last reply I told that maybe we should be able to name the type of null. I think this relates to TBottom too a bit.
>
> https://github.com/dlang/DIPs/blob/40352337053998885fbd0fe2718c300a322d3996/DIPs/DIP1NNN-DK.md

This is everything I wished for. It basically exactly resembles the results of the lengthy discussion H. S. Theo and I had in the review thread for Walter‘s original bottom type suggestion. And it even covers a few additional details we had not thought about. I can’t wait for this DIP to go into review. Thanks a lot to the DIP author. You have my biggest respect for writing a fleshed out proposal of this!

December 07, 2019
On Friday, 6 December 2019 at 23:25:30 UTC, Johannes Loher wrote:
> On Tuesday, 3 December 2019 at 10:06:22 UTC, Mike Parker wrote:
>> On Tuesday, 3 December 2019 at 10:03:22 UTC, Basile B. wrote:
>>
>>>
>>> That's interesting details of D developement. Since you reply to the first message I think you have not followed but in the last reply I told that maybe we should be able to name the type of null. I think this relates to TBottom too a bit.
>>
>> https://github.com/dlang/DIPs/blob/40352337053998885fbd0fe2718c300a322d3996/DIPs/DIP1NNN-DK.md
>
> This is everything I wished for. It basically exactly resembles the results of the lengthy discussion H. S. Theo and I had in the review thread for Walter‘s original bottom type suggestion. And it even covers a few additional details we had not thought about. I can’t wait for this DIP to go into review. Thanks a lot to the DIP author. You have my biggest respect for writing a fleshed out proposal of this!

nice.

Kotlin has this as well, with Unit as void and Nothing as
noreturn.

So for example this compiles without complaint:

  fun infinite(f: () -> Unit) {
      while (true) {
          f()
      }
  }

  fun main() {
      infinite { println(".") }
      println("goodbye")
  }

Where 'infinite' has an implcit Unit return type, but this
warns that the "goodbye" will never happen:

  fun infinite(f: () -> Unit): Nothing {
      while (true) {
          f()
      }
  }

  fun main() {
      infinite { println(".") }
      println("goodbye")
  }

This might be more important for resources that never get
closed, or secrets are never scrubbed from memory, due to
someone putting those tasks after a function like 'infinite'
without noticing.

... noreturn local variables are pretty gross, though.

1 2 3
Next ›   Last »