Jump to page: 1 213  
Page
Thread overview
If you could make any changes to D, what would they look like?
Oct 20, 2021
SealabJaster
Oct 20, 2021
IGotD-
Oct 20, 2021
SealabJaster
Oct 20, 2021
IGotD-
Oct 20, 2021
bauss
Oct 20, 2021
jmh530
Oct 20, 2021
IGotD-
Oct 20, 2021
IGotD-
Oct 20, 2021
jmh530
Oct 20, 2021
IGotD-
Oct 20, 2021
H. S. Teoh
Oct 20, 2021
Elronnd
Oct 20, 2021
SealabJaster
Oct 20, 2021
Adam D Ruppe
Oct 20, 2021
H. S. Teoh
Oct 20, 2021
russhy
Oct 20, 2021
IGotD-
Oct 20, 2021
H. S. Teoh
Oct 20, 2021
Adam D Ruppe
Oct 20, 2021
Elronnd
Oct 21, 2021
Tejas
Oct 20, 2021
Guillaume Piolat
Oct 20, 2021
Adam D Ruppe
Oct 20, 2021
H. S. Teoh
Oct 20, 2021
Ali Çehreli
Oct 20, 2021
H. S. Teoh
Oct 20, 2021
Basile B.
Oct 20, 2021
kyle
Oct 21, 2021
12345swordy
Oct 21, 2021
kyle
Oct 20, 2021
Kagamin
Oct 20, 2021
SealabJaster
Oct 20, 2021
H. S. Teoh
Oct 21, 2021
Sebastiaan Koppe
Oct 22, 2021
Elronnd
Oct 24, 2021
Gavin Ray
Oct 24, 2021
Imperatorn
Oct 24, 2021
Paul Backus
Oct 24, 2021
Basile B.
Oct 24, 2021
Paul Backus
Re: If you could make any changes to D, what would they look lik
Oct 24, 2021
Paul Backus
Oct 25, 2021
Basile B.
Oct 25, 2021
H. S. Teoh
Oct 26, 2021
Basile B.
Oct 26, 2021
H. S. Teoh
Oct 25, 2021
Gavin Ray
Oct 24, 2021
Menshikov
Oct 24, 2021
Ben Jones
Oct 25, 2021
zjh
Oct 25, 2021
zjh
Oct 25, 2021
Guillaume Piolat
Oct 25, 2021
IGotD-
Oct 25, 2021
H. S. Teoh
Oct 25, 2021
IGotD-
Oct 25, 2021
Paul Backus
Oct 25, 2021
IGotD-
Oct 25, 2021
Paul Backus
Oct 25, 2021
Paul Backus
Oct 25, 2021
Paul Backus
Oct 25, 2021
Paul Backus
Oct 27, 2021
Dukc
Oct 27, 2021
IGotD-
Oct 27, 2021
Dukc
Oct 27, 2021
H. S. Teoh
Oct 28, 2021
Dennis
Oct 28, 2021
Dukc
Oct 28, 2021
Dennis
Oct 28, 2021
Dukc
Oct 28, 2021
max haughton
Oct 28, 2021
Dukc
Oct 28, 2021
max haughton
Oct 28, 2021
Patrick Schluter
Oct 28, 2021
Dukc
Oct 28, 2021
H. S. Teoh
Oct 29, 2021
Patrick Schluter
Oct 29, 2021
H. S. Teoh
Oct 29, 2021
Paul Backus
Oct 29, 2021
H. S. Teoh
Oct 29, 2021
Adam Ruppe
Oct 30, 2021
Patrick Schluter
Nov 02, 2021
H. S. Teoh
Nov 02, 2021
Patrick Schluter
Nov 02, 2021
H. S. Teoh
Oct 30, 2021
Paul Backus
Oct 30, 2021
H. S. Teoh
Oct 27, 2021
H. S. Teoh
Oct 27, 2021
Dukc
Oct 27, 2021
H. S. Teoh
Oct 28, 2021
Paul Backus
Oct 28, 2021
Dukc
Oct 25, 2021
Dennis
Oct 25, 2021
Guillaume Piolat
Oct 25, 2021
Adam D Ruppe
Oct 25, 2021
Dennis
Oct 25, 2021
Adam D Ruppe
Oct 25, 2021
H. S. Teoh
Oct 25, 2021
Paul Backus
Oct 26, 2021
H. S. Teoh
Oct 25, 2021
H. S. Teoh
Oct 25, 2021
Adam D Ruppe
Oct 25, 2021
Dennis
Oct 25, 2021
Dukc
Oct 25, 2021
Dukc
Oct 25, 2021
H. S. Teoh
Oct 25, 2021
victoroak
Oct 27, 2021
Bienlein
Oct 30, 2021
harakim
October 20, 2021

Just for giggles, without pesky things like breaking changes; rational thinking, logical reasoning behind the changes, etc.

What interesting changes would you make to the language, and what could they possibly look like?

Here's a small example of some things I'd like.

import std;

interface Animal
{
    void speak(string language);
}

struct Dog
{
    @nogc @nothrow @pure @safe
    static void speak(string l)
    {
        // Pattern matching of some kind
        // With strings this is just a fancy switch statement, but this is the gist of it
        match l with
        {
            "english" => writeln("woof"),
            "french" => writeln("le woof"),
            _ => writeln("foow")
        }
    }
}

struct Cat
{
    // Remove historical baggage. Make old attributes into `@` attributes
    @nogc @nothrow @pure @safe
    static void speak()
    {
        writeln("meow")
    }
}

// ? for "explicitly nullable"
void doSpeak(alias T)(string? language)
if(is(T == struct) && match(T : Animal)) // Match structs against an interface.
{
    // immutable by default. ?? is the same as in C#
    auto lang = language ?? "UNKNOWN";

    // So of course we'd need a mutable keyword of some sort
    mutable output = $"{__traits(identifier, T)} speaking in {lang}"; // String interpolation
    writeln(output);
    T.speak(lang);
}

void main()
{
    doSpeak!Dog;
    doSpeak!Cat; // Should be a compiler error since it fails the `match` statement
}
October 20, 2021

On Wednesday, 20 October 2021 at 09:47:54 UTC, SealabJaster wrote:

>

Priority 1 would introducing managed pointers (aka reference type, fat pointers) in order to fix the no 1 scare of them all, the GC.

October 20, 2021
- Limited implicit conversions (adam has spoken about this before)

- First class support for non-nullable pointers and explicitly optional pointers

- Class instances should not be reference types

- Macros (cf core.reflect/codegen)

- || and && should not coerce to boolean (x || y is x ? x : y (but without double eval); x && y is x ? y : typeof(y).init)
October 20, 2021

On Wednesday, 20 October 2021 at 10:06:30 UTC, IGotD- wrote:

>

Priority 1 would introducing managed pointers (aka reference type, fat pointers) in order to fix the no 1 scare of them all, the GC.

So something like int^ to denote a GC pointer, and int* for a raw pointer?

October 20, 2021

On Wednesday, 20 October 2021 at 10:23:27 UTC, SealabJaster wrote:

>

So something like int^ to denote a GC pointer, and int* for a raw pointer?

Something like that, which is exactly the syntax of "Managed C++".

October 20, 2021
On Wednesday, 20 October 2021 at 10:07:40 UTC, Elronnd wrote:
> - First class support for non-nullable pointers and explicitly optional pointers

We can only dream.

> - Class instances should not be reference types

Interesting opinion. So classes would essentially be structs with a v-table (similar to C++ I believe)? From a quick think about how things would work, it seems like it's simplify generic code littered with `static if(is(T == class))`.

> - || and && should not coerce to boolean (x || y is x ? x : y (but without double eval); x && y is x ? y : typeof(y).init)

I like that. It's similar to the likes of Lua where you can go `var = var or {}`
October 20, 2021

On Wednesday, 20 October 2021 at 10:26:52 UTC, IGotD- wrote:

>

On Wednesday, 20 October 2021 at 10:23:27 UTC, SealabJaster wrote:

>

So something like int^ to denote a GC pointer, and int* for a raw pointer?

Something like that, which is exactly the syntax of "Managed C++".

I'm not gonna lie, Managed C++ was actually nice

October 20, 2021
On Wednesday, 20 October 2021 at 10:28:35 UTC, SealabJaster wrote:
> On Wednesday, 20 October 2021 at 10:07:40 UTC, Elronnd wrote:
>> - Class instances should not be reference types
>
> Interesting opinion. So classes would essentially be structs with a v-table

Well, one idea I heard last week that I don't loathe and despise is that classes are always *explicit* references.

class Object {}

void foo(Object* o){}

That'd be the new syntax for what we have today. But:

void foo(Object o) {} // error: cannot declare variable of class value type; the rule is still they're always references


One of the benefits of this is there's now a place for rebindable:


void foo(const(Object)* o) {} // const object, but you can rebind the reference



That const ref thing has come up for about as long as D has had const.


I don't really think it is worth the hassle but it is interesting in that it solves some old syntax worries.
October 20, 2021
On Wed, Oct 20, 2021 at 09:47:54AM +0000, SealabJaster via Digitalmars-d wrote:
> Just for giggles, without pesky things like breaking changes; rational thinking, logical reasoning behind the changes, etc.
> 
> What interesting changes would you make to the language, and what could they possibly look like?

1) Kill current int promotion rules with fire.

2) Kill autodecoding with the same.

3) Kill the current class hierarchy, make ProtoObject -> Object.

4) The compiler would infer which function parameters need to be runtime and which can be completely resolved at compile-time. You wouldn't need to separate the two; it would be inferred for you.  Well, OK, in some cases this is not possible, then you have to annotate it. But otherwise, it should be automatic.  Template functions and "ordinary" functions would be one and the same.  The compiler figures out for you which parameters should be compile-time and which should be runtime.  Flipping a switch would toggle between optimizing for performance (maximize compile-time binding) vs size (minimize compile-time binding, genericize parameters to accept polymorphic runtime types).

5) Compiler would auto-rewrite your source code to add/update function annotations so that you never have to actually write them yourself. This includes annotations that only the compiler can figure out, like flow analysis information, code invariants, etc., stuff that would solve a bunch of problems with separate compilation not having full information about a function.  Also, the compiler will auto-fix typos for you (and update the source code) if it makes the code compilable.

6) Completely pay-as-you-go std library / codegen, i.e., if your program consists of `void main() {}` it should weigh less than 1KB. (In fact, it should weigh 45 bytes.[1] :-D)  If you writeln("hello world") it should not pull in code for formatting floats.  Executables would contain the absolute bare minimum to do what it's supposed to do, not a single byte more.

7) In-contracts should run in the caller, not the callee.

8) There should be a new standard library function called dwimnwis,[2] that uses neural networks to predict what the programmer meant rather than what he actually wrote, and does that instead of what the source code says.


[1] http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html [2] Do What I Mean, Not What I Said.


T

-- 
I am Ohm of Borg. Resistance is voltage over current.
October 20, 2021
On Wed, Oct 20, 2021 at 10:06:30AM +0000, IGotD- via Digitalmars-d wrote: [...]
> Priority 1 would introducing managed pointers (aka reference type, fat pointers) in order to fix the no 1 scare of them all, the GC.

IMNSHO, priority 1 would be to kill GC-phobia with fire. ;-)  Everything else follows naturally after that.


T

-- 
No! I'm not in denial!
« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11