November 09, 2021
On 08.11.21 15:04, Atila Neves wrote:
> On Friday, 5 November 2021 at 21:22:12 UTC, victoroak wrote:
>> On Friday, 5 November 2021 at 17:02:05 UTC, Atila Neves wrote:
>>>
>>>> - @safe `void` initialization
>>>
>>> For what types? It doesn't compile for pointers, for instance, and I don't see why void initialising an int would be unsafe.
>>>
>>>> - .init
>>>
>>> Because?
>>>
>>
>> Well, I can't answer for him but `void` initialization and `.init` makes it impossible to have any meaningful constraint on a type. And some types may depend on these constraints to maintain safety.
>>
>> ```d
>> import std.stdio;
>>
>> struct LimitedInt(int min, int max)
>> {
>>     @disable this();
>>
>>     this(int number)
>>     {
>>         assert(number >= min);
>>         assert(number <= max);
>>         _number = number;
>>     }
>>
>>     private int _number;
>> }
>>
>> void main() @safe
>> {
>>     LimitedInt!(1, 1000) x = void;
>>     auto y = LimitedInt!(1, 1000).init;
>>     writeln(x);
>>     writeln(y);
>> }
>> ```
>>
>> It's `@safe` in this example but there's no way to enforce these constraints when you have those.
> 
> Interesting. Adding an invariant causes compilation to fail:
> 
> ```
> foo.d(27): Error: variable `foo.main.x` `void` initializers for structs with invariants are not allowed in safe functions
> ```
> 
> 

Well, that makes some sense, but a struct can have an invariant without actually having it spelled out explicitly in the source code. Furthermore, adding contracts actually makes code less safe in -release mode.
November 09, 2021
On 09.11.21 16:39, Atila Neves wrote:
> On Tuesday, 9 November 2021 at 13:26:20 UTC, Ola Fosheim Grøstad wrote:
>> On Tuesday, 9 November 2021 at 11:37:49 UTC, Atila Neves wrote:
>>>> It means you now loose context
>>>
>>> I don't see how.
>>
>> In D you can throw a wide variety of exceptions and propagate them without even knowing that they were thrown. D even retains the exception chain… (perhaps too much context for most use cases). Clearly you loose context by "?" in comparison? Python also allows you to trace the stack… that is a lot of context…
> 
> If there are no exceptions and one is returning regular values, then the call stack is... the call stack. Given that "?" returns the original failure with whatever extra data it had, I really don't see what the difference is.
> 
> 

Having a stack trace with line numbers is a big deal in case the exception was unexpected.
November 09, 2021

On Tuesday, 9 November 2021 at 16:37:37 UTC, Timon Gehr wrote:

>

On 08.11.21 15:04, Atila Neves wrote:

>

On Friday, 5 November 2021 at 21:22:12 UTC, victoroak wrote:

>

[...]

Interesting. Adding an invariant causes compilation to fail:

foo.d(27): Error: variable `foo.main.x` `void` initializers for structs with invariants are not allowed in safe functions

Well, that makes some sense, but a struct can have an invariant without actually having it spelled out explicitly in the source code. Furthermore, adding contracts actually makes code less safe in -release mode.

IMHO -release mode really shouldn't be used, but since contracts are supposed to prevent bugs from occurring, hopefully testing "proved" that "none" exist.

In this case specifically, even with -release one gets a compiler error, which is enough of a reason to add one methinks.

November 09, 2021
On Tuesday, 9 November 2021 at 16:44:50 UTC, Timon Gehr wrote:
> On 09.11.21 16:39, Atila Neves wrote:
>> On Tuesday, 9 November 2021 at 13:26:20 UTC, Ola Fosheim Grøstad wrote:
>>> [...]
>> 
>> If there are no exceptions and one is returning regular values, then the call stack is... the call stack. Given that "?" returns the original failure with whatever extra data it had, I really don't see what the difference is.
>> 
>> 
>
> Having a stack trace with line numbers is a big deal in case the exception was unexpected.

Good point. I hadn't thought of that.
November 09, 2021

On Tuesday, 9 November 2021 at 17:16:52 UTC, Atila Neves wrote:

> >

Having a stack trace with line numbers is a big deal in case the exception was unexpected.

Good point. I hadn't thought of that.

Not a big deal IMO. Stack traces are not the main feature of exceptions anyway. Now granted that the error is a bit harder to track down without the stack trace but we don't put stack traces to nulls or NaNs either. We insert logging statements separately if we want to prepare for tracking an unexpected bug.

November 10, 2021

On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:

>

I'm brainstorming about what I'll talk about at DConf, and during a conversation with Walter I thought it might be cool to talk about:

  • Worst features implemented in a non-toy language
  • Worst features (in your opinion) in D
  • Features you'd like to see in D

Ideas? Examples?

Thanks!

I'd say being able to do the same thing, multiple ways.

IMO. It's the worst feature, and yet, it's also the best feature.

November 10, 2021
On 10/16/21 1:12 AM, Walter Bright wrote:
> On 10/12/2021 2:38 PM, Timon Gehr wrote:
>> - non-lexical variable lifetimes (probably not happening)
> 
> It's already implemented for @live.


Specifically, I would like it to influence scoping.

```d
int x=2;
int y=move(x);
int z=x; // error: undefined identifier x (was moved away)

int y=move(y); // ok
```
November 10, 2021
On Wednesday, 10 November 2021 at 07:09:34 UTC, Timon Gehr wrote:
> On 10/16/21 1:12 AM, Walter Bright wrote:
>> On 10/12/2021 2:38 PM, Timon Gehr wrote:
>>> - non-lexical variable lifetimes (probably not happening)
>> 
>> It's already implemented for @live.
>
>
> Specifically, I would like it to influence scoping.
>
> ```d
> int x=2;
> int y=move(x);
> int z=x; // error: undefined identifier x (was moved away)
>
> int y=move(y); // ok
> ```

That would be a good start. I would support that.
November 10, 2021
On Wednesday, 10 November 2021 at 14:15:58 UTC, Stefan Koch wrote:
> On Wednesday, 10 November 2021 at 07:09:34 UTC, Timon Gehr wrote:
>> Specifically, I would like it to influence scoping.
>>
>> ```d
>> int x=2;
>> int y=move(x);
>> int z=x; // error: undefined identifier x (was moved away)
>>
>> int y=move(y); // ok
>> ```
>
> That would be a good start. I would support that.

Yeah, that would be lovely.
November 10, 2021
On Wed, Nov 10, 2021 at 02:17:28PM +0000, Sebastiaan Koppe via Digitalmars-d wrote:
> On Wednesday, 10 November 2021 at 14:15:58 UTC, Stefan Koch wrote:
> > On Wednesday, 10 November 2021 at 07:09:34 UTC, Timon Gehr wrote:
> > > Specifically, I would like it to influence scoping.
> > > 
> > > ```d
> > > int x=2;
> > > int y=move(x);
> > > int z=x; // error: undefined identifier x (was moved away)
> > > 
> > > int y=move(y); // ok
> > > ```
> > 
> > That would be a good start. I would support that.
> 
> Yeah, that would be lovely.

That would allow a better implementation of ownership tracking.


T

-- 
People walk. Computers run.