November 01

On Monday, 1 November 2021 at 09:45:10 UTC, glis-glis wrote:

>

An English-agnostic programming language would be nice to help non-native English speakers to get into programming more easily, but how would you replace keywords like "if", "while" or "for"?

You could replace "if" with "?", "??" or "¿" and use "⟳" for loops.

However, I've found that this makes code harder to read as you no longer get a visual separation of "numeric expressions" and the main structure of the program.

This presumes that you use a regular text editor. If you create a graphical editor, you probably could use only symbols or pictures with good effect, but it is a lot of work to develop such editors.

November 05
On Tuesday, 12 October 2021 at 21:38:48 UTC, Timon Gehr wrote:
> On 10/11/21 5:59 PM, Atila Neves wrote:
>> ...
>
> This is likely to be incomplete or overly abstract, but here's my approximate take:
>
>> * Worst features implemented in a non-toy language
>
> - Turing-complete constructors

Care to explain?

> - @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.

> - @safe extern(C) function prototypes

Instead of @trusted, you mean?

> - .init

Because?

> - separation of templates and CTFE

What would it look like if they weren't separated?

> - interaction of type qualifiers with reference types

I'd love to know what you mean by this.


November 05

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.

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.

November 05
On Fri, Nov 05, 2021 at 09:22:12PM +0000, victoroak via Digitalmars-d 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.

@safe does not mean enforcing type constraints.  It means *memory* safety.  The above code exhibits no memory unsafety, even though constraints are violated and the output is, ostensibly, wrong because of broken constraints.


T

-- 
There are four kinds of lies: lies, damn lies, and statistics.
November 05
On Friday, 5 November 2021 at 21:46:35 UTC, H. S. Teoh wrote:
>
> @safe does not mean enforcing type constraints.  It means *memory* safety.  The above code exhibits no memory unsafety, even though constraints are violated and the output is, ostensibly, wrong because of broken constraints.
>
>

`.init` was not mentioned as breaking `@safe` just as a bad feature and I was answering why I think it is a bad feature.

But the presence of both `.init` and @safe `void` initialization makes it way harder to write correct `@trusted` code that depends on some constraints because you can't really enforce them.


November 06
On Friday, 5 November 2021 at 21:54:27 UTC, victoroak wrote:
> On Friday, 5 November 2021 at 21:46:35 UTC, H. S. Teoh wrote:
>>
>> @safe does not mean enforcing type constraints.  It means *memory* safety.  The above code exhibits no memory unsafety, even though constraints are violated and the output is, ostensibly, wrong because of broken constraints.
>>
>>
>
> `.init` was not mentioned as breaking `@safe` just as a bad feature and I was answering why I think it is a bad feature.
>
> But the presence of both `.init` and @safe `void` initialization makes it way harder to write correct `@trusted` code that depends on some constraints because you can't really enforce them.

...which is one of the reasons we need @system variables:

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1035.md
November 06

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 line of reasoning for not having a feature is Go that refuses to add exceptions because they don't think people will do cleanup correctly, instead you are faced with 150% more error-handling code (or code that ignore errors).

Error handling in Rust also looks pretty atrocious, but I haven't written anything more than toy programs in Rust.

November 06

On Saturday, 6 November 2021 at 11:45:18 UTC, Ola Fosheim Grøstad wrote:

>

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 line of reasoning for not having a feature is Go that refuses to add exceptions because they don't think people will do cleanup correctly, instead you are faced with 150% more error-handling code (or code that ignore errors).

Error handling in Rust also looks pretty atrocious, but I haven't written anything more than toy programs in Rust.

Go has exceptions, although they don't call them as such (panic/recover).

Rust error handling is not easy by default, however there are some helper libraries to make it easier to do rail oriented programming, and they are in the process of adding vocabulary types for improved error handling, based on the experience of those libraries.

November 06

On Saturday, 6 November 2021 at 19:13:11 UTC, Paulo Pinto wrote:

>

Go has exceptions, although they don't call them as such (panic/recover).

They discourage using it for regular errors, and Go programmers seem to swallow the very noice error-checking regime. Panic recover is also quite clunky and runtime dependent. Yes, I personally use it as clunky hack to emulate exceptions, but it is much less maintainable.

>

programming, and they are in the process of adding vocabulary types for improved error handling, based on the experience of those libraries.

Are they extending the language?

November 06

On Saturday, 6 November 2021 at 19:36:19 UTC, Ola Fosheim Grøstad wrote:

>

On Saturday, 6 November 2021 at 19:13:11 UTC, Paulo Pinto wrote:

>

Go has exceptions, although they don't call them as such (panic/recover).

They discourage using it for regular errors, and Go programmers seem to swallow the very noice error-checking regime. Panic

I meant "very noisy"…

15 16 17 18 19 20 21 22 23 24 25 26 27