www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Shopping for template languages

reply monkyyy <crazymonkyyy gmail.com> writes:
Its important to review decisions every once in a while, so, why 
am I tolerating d?

Last year my answer was its the best template language, c++ is 
ugly as sin and compiles slow, rust is even worse. My goal is to 
be where I believe sanity is and that is extreme metaprogramming 
on iterators(api between data and functions) preferably ranges(3 
functions primitive, relating to for loops; optional extensions 
for array-like behaviors when possible); with an extensive std 
pushing the boundaries.

*Is that still true?*

preemptive responses to ovisous candidates:

go: go only implements generics and is very irritating about 
"unused code"; generics are not a replacement for template hell.

swift: I worry about the apple connection(even if its weakening) 
and when I google swift iterators" it seems to be the oo take.

c3: Im unsure how strong ast marcos are? can anyone claim they 
are as flexable as templates

zig: zig while fantastic, lacks a fundamental piece, 
metaprogramming
Aug 07
next sibling parent reply matheus <matheus gmail.com> writes:
On Wednesday, 7 August 2024 at 19:44:57 UTC, monkyyy wrote:

 ...

 c3: Im unsure how strong ast marcos are? can anyone claim they 
 are as flexable as templates

 ...


Never heard of this one, then looking online what I found? A 
video from Mike Shah reviewing it... Betrayer?

Just joking. =]

Anyway, I wish there was a C version or a D option for auto free 
after end of scope for memory manually allocated for example.

Matheus.
Aug 07
next sibling parent Sergey <kornburn yandex.ru> writes:
On Wednesday, 7 August 2024 at 20:26:07 UTC, matheus wrote:

 Never heard of this one, then looking online what I found? A 
 video from Mike Shah reviewing it... Betrayer?


tsoding videos about C3 are even better =)
Aug 07
prev sibling next sibling parent reply An Pham <home home.com> writes:
On Wednesday, 7 August 2024 at 20:26:07 UTC, matheus wrote:

 Anyway, I wish there was a C version or a D option for auto 
 free after end of scope for memory manually allocated for 
 example.

 Matheus.


No need language feature - here is auto free after scope
compile with -debug option

import core.stdc.stdlib : malloc;
import std.stdio : writeln;

struct Foo
{
     int x;
}

struct Owned(T)
{
     this(void* v) nothrow  nogc
     {
         debug writeln("constructor");
         this.v = cast(T*)v;
     }

     ~this() nothrow  nogc
     {
         debug writeln("destructor");
         import core.stdc.stdlib : free;
         if (v)
         {
             free(v);
             debug writeln("free");
         }
     }

     static typeof(this) malloc() nothrow  nogc // same attribute 
as stdlib.malloc
     {
         return typeof(this)(.malloc(T.sizeof));
     }

     T* v;
     alias this=v;
}

void main()
{
     { // Simulate scope
     auto foo = Owned!Foo(malloc(Foo.sizeof));
     foo.x = 10;
     assert(foo.x == 10);
     writeln(foo.x);
     }

     { // Simulate scope
     auto foo = Owned!Foo.malloc;
     foo.x = 100;
     assert(foo.x == 100);
     writeln(foo.x);
     }
}
Aug 07
parent matheus <matheus gmail.com> writes:
On Wednesday, 7 August 2024 at 21:39:06 UTC, An Pham wrote:

 On Wednesday, 7 August 2024 at 20:26:07 UTC, matheus wrote:

 Anyway, I wish there was a C version or a D option for auto 
 free after end of scope for memory manually allocated for 
 example.

 Matheus.


 No need language feature - here is auto free after scope
 compile with -debug option

 ...


Yes I understand that and by the way I used to do the malloc 
wrapping in other languages too.

That works, but I would like that as feature by default, because 
I could be consuming other source/libraries, and that feature 
would prevent leaking.


written in C which on the other hand had a memory leak, in that 
case since the lib wasn't ours, the cheap way to solve was 
running it inside a process and killed it.

But thanks again for the example, this obvious could be a nice 
solution.

Matheus.
Aug 07
prev sibling parent Mike Shah <mshah.475 gmail.com> writes:
On Wednesday, 7 August 2024 at 20:26:07 UTC, matheus wrote:

 On Wednesday, 7 August 2024 at 19:44:57 UTC, monkyyy wrote:

 ...

 c3: Im unsure how strong ast marcos are? can anyone claim they 
 are as flexable as templates

 ...


 Never heard of this one, then looking online what I found? A 
 video from Mike Shah reviewing it... Betrayer?

 Just joking. =]

 Anyway, I wish there was a C version or a D option for auto 
 free after end of scope for memory manually allocated for 
 example.

 Matheus.



Hehe, I'm always trying new languages. 😊

No plans to leave D anytime soon 👍😁
Aug 08
prev sibling parent reply cc <cc nevernet.com> writes:
On Wednesday, 7 August 2024 at 19:44:57 UTC, monkyyy wrote:

 why am I tolerating d?


I really, really like D's templating and metaprogramming.  You 
get the engine bits and wiring in under the hood, and then the 
front-facing interface is clean and expressive, with a huge 
amount of the work being done compile-time.  It's just way more 
fun to work in than anything else.

```d
 TABLE("characters")
struct Character {
	enum Class {
		NULL, FIGHTER, KNIGHT, ARCHER, MAGE, HEALER
	}
	enum Elements {
		NONE = 0,
		EARTH = 1<<0,
		AIR   = 1<<1,
		FIRE  = 1<<2,
		WATER = 1<<3,
	}
	 NULLABLE  PRIMARY int id; // auto_increment
	string name;
	 ENUMSTRING  COLUMN("class") Class cClass;
	int rarity;
	 ENUMSTRING Elements elements;
	SysTime mdate;
}

void main() {
	auto db = DBH("chars.db"); // SQLite

	auto table = db.createTable!Character;
	table.insert(Character(name: "Bob", cClass: 
Character.Class.KNIGHT, mdate: Clock.currTime));
	table.insert(Character(name: "Joe", elements: 
Character.Elements.EARTH | Character.Elements.FIRE, mdate: 
Clock.currTime));

	auto sth = db.query("SELECT * FROM characters;");
	foreach (chara; sth.as!Character) {
		writeln(chara.toStringer);
		auto u = chara.updater;
		u.mdate = Clock.currTime;
		db.update(u);
	}
}
```
```
Character(id:1, name:"Bob", cClass:KNIGHT, rarity:0, 
elements:NONE, mdate:2024-Aug-09 00:18:05.457)
Character(id:2, name:"Joe", cClass:NULL, rarity:0, 
elements:EARTH|FIRE, mdate:2024-Aug-09 00:18:05.465)
```
```
sqlite> SELECT * FROM characters;
┌────┬──────┬────────┬────────┬────────────┬───────────────┐
│ id │ name │ class  │ rarity │  elements  │     mdate     │
├────┼──────┼────────┼────────┼────────────┼───────────────┤
│ 1  │ Bob  │ KNIGHT │ 0      │ NONE       │ 1723130285473 │
│ 2  │ Joe  │ NULL   │ 0      │ EARTH,FIRE │ 1723130285482 │
└────┴──────┴────────┴────────┴────────────┴───────────────┘
```

I'm aching to improve this some more if we could get a fix to 
allow this:
```d
void foo(Nullable!int d) {}
foo(3); // compilation error
```
Aug 08
next sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Thursday, 8 August 2024 at 15:31:11 UTC, cc wrote:

 On Wednesday, 7 August 2024 at 19:44:57 UTC, monkyyy wrote:

 why am I tolerating d?


 I really, really like D's templating and metaprogramming.



 with an extensive std pushing the boundaries.




I cant mantain 1000 projects, or 100 projects or probably even 
12, can I manage 3?. I love the meta programming, but I feel its 
wasted without major pushes to make generic code.

Templates come at a steep cost I dont think your getting a return 
if you reuse a block of code 3 times(an over estimation, even 
filter may not be used in every project), and thats my templates 
the std and the official style guide wants 
templates+contracts+formalized interfaces+bureaucracy documents
Aug 08
prev sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Thursday, 8 August 2024 at 15:31:11 UTC, cc wrote:

 `table.insert(Character(name: "Bob", cClass: 
 Character.Class.KNIGHT, mdate: Clock.currTime));`



D needs `.ENUM` ASAP, this is painful to look at
Aug 08
parent reply Kapendev <alexandroskapretsos gmail.com> writes:
On Thursday, 8 August 2024 at 17:15:48 UTC, ryuukk_ wrote:

 On Thursday, 8 August 2024 at 15:31:11 UTC, cc wrote:

 Character.Class.KNIGHT, mdate: Clock.currTime));`



 D needs `.ENUM` ASAP, this is painful to look at


Yeah, the `.enum` syntax in some other languages is nice. Would 
be nice to have.


 templates


Nim? Has bad docs, but the templates are a bit scary. You might 
like it, moonkeyy.
Aug 08
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Thursday, 8 August 2024 at 19:13:53 UTC, Kapendev wrote:

 Nim? Has bad docs, but the templates are a bit scary. You might 
 like it, moonkeyy.


I really hate python, and I dont know if ast macros are a 
replacement for templates but I'm leaning no
Aug 08
parent IchorDev <zxinsworld gmail.com> writes:
On Thursday, 8 August 2024 at 19:30:29 UTC, monkyyy wrote:

 I dont know if ast macros are a replacement for templates but 
 I'm leaning no


Certainly not from what people say about Rust.
Aug 10
prev sibling parent reply IchorDev <zxinsworld gmail.com> writes:
On Thursday, 8 August 2024 at 19:13:53 UTC, Kapendev wrote:

 On Thursday, 8 August 2024 at 17:15:48 UTC, ryuukk_ wrote:

 On Thursday, 8 August 2024 at 15:31:11 UTC, cc wrote:

 Character.Class.KNIGHT, mdate: Clock.currTime));`



 D needs `.ENUM` ASAP, this is painful to look at


 Yeah, the `.enum` syntax in some other languages is nice. Would 
 be nice to have.


Then put pressure on Walter to make it happen! He’s been very 
apprehensive to accept something like that even though it’s kinda 
crucial to Rikki’s version of sumtypes.
Aug 10
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Saturday, 10 August 2024 at 11:20:23 UTC, IchorDev wrote:

 On Thursday, 8 August 2024 at 19:13:53 UTC, Kapendev wrote:

 On Thursday, 8 August 2024 at 17:15:48 UTC, ryuukk_ wrote:

 On Thursday, 8 August 2024 at 15:31:11 UTC, cc wrote:

 Character.Class.KNIGHT, mdate: Clock.currTime));`



 D needs `.ENUM` ASAP, this is painful to look at


 Yeah, the `.enum` syntax in some other languages is nice. 
 Would be nice to have.


 Then put pressure on Walter to make it happen! He’s been very 
 apprehensive to accept something like that even though it’s 
 kinda crucial to Rikki’s version of sumtypes.


I am a nobody, i can't convince anyone

Rikki should submit a PR, make it available trhought a -preview, 
and we move on, at some point we vote and we see how it goes, 
just like Walter did for bitfields preview
Aug 10
parent reply IchorDev <zxinsworld gmail.com> writes:
On Saturday, 10 August 2024 at 12:05:31 UTC, ryuukk_ wrote:

 I am a nobody, i can't convince anyone


Nobody? You??


 Rikki should submit a PR, make it available trhought a 
 -preview, and we move on, at some point we vote and we see how 
 it goes, just like Walter did for bitfields preview


I think Walter would likely block such a PR. Bitfields can get in 
that way because it’s Walter’s thing, this is different.
Aug 10
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 11/08/2024 12:26 AM, IchorDev wrote:

     Rikki should submit a PR, make it available trhought a -preview, and
     we move on, at some point we vote and we see how it goes, just like
     Walter did for bitfields preview
 
 I think Walter would likely block such a PR. Bitfields can get in that 
 way because it’s Walter’s thing, this is different.


Until I get the go ahead, given his strong opinions in the past, that is 
my current assumption.
Aug 10
next sibling parent claptrap <clap trap.com> writes:
On Saturday, 10 August 2024 at 12:42:29 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 11/08/2024 12:26 AM, IchorDev wrote:

     Rikki should submit a PR, make it available trhought a 
 -preview, and
     we move on, at some point we vote and we see how it goes, 
 just like
     Walter did for bitfields preview
 
 I think Walter would likely block such a PR. Bitfields can get 
 in that way because it’s Walter’s thing, this is different.


 Until I get the go ahead, given his strong opinions in the 
 past, that is my current assumption.


WAL : I'm sorry Rikki I cant do that.
Aug 10
prev sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Saturday, 10 August 2024 at 12:42:29 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 11/08/2024 12:26 AM, IchorDev wrote:

     Rikki should submit a PR, make it available trhought a 
 -preview, and
     we move on, at some point we vote and we see how it goes, 
 just like
     Walter did for bitfields preview
 
 I think Walter would likely block such a PR. Bitfields can get 
 in that way because it’s Walter’s thing, this is different.


 Until I get the go ahead, given his strong opinions in the 
 past, that is my current assumption.


Why are people scared of walter? he won't eat you, i can't tell 
you what you should be doing, but don't let anybody hold you 
back, push harder, make it a -preview flag

Many people voiced their positive opinion, we'll back you

Too many things are happening in closed doors, it's sad
Aug 10
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 11/08/2024 5:50 AM, ryuukk_ wrote:

 On Saturday, 10 August 2024 at 12:42:29 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 On 11/08/2024 12:26 AM, IchorDev wrote:

     Rikki should submit a PR, make it available trhought a -preview, and
     we move on, at some point we vote and we see how it goes, just like
     Walter did for bitfields preview

 I think Walter would likely block such a PR. Bitfields can get in 
 that way because it’s Walter’s thing, this is different.


 Until I get the go ahead, given his strong opinions in the past, that 
 is my current assumption.


 
 Why are people scared of walter? he won't eat you, i can't tell you what 
 you should be doing, but don't let anybody hold you back, push harder, 
 make it a -preview flag


I'm not scared of him, also this isn't something you'd put under a 
preview flag.


 Many people voiced their positive opinion, we'll back you
 
 Too many things are happening in closed doors, it's sad


That's not what is going on here.

I asked Walter to look into it and get back to me 2 months ago at the 
monthly meeting and prepared the materials he requested.

He has been on the backend, a very different subject matter so I haven't 
been wanting to force it.

I also know he has strong opinions about it, which offsets my desire to 
waste my time on something he'll likely want to say no to.

However, it's clear to me that I'm wasting my time in not doing it.

I have no guarantees about if I can get to it in the next two weeks. The 
next two weeks is going to be spent on escape analysis, as we're looking 
at replacing it.
Aug 11
parent reply IchorDev <zxinsworld gmail.com> writes:
On Sunday, 11 August 2024 at 07:11:01 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 The next two weeks is going to be spent on escape analysis, as 
 we're looking at replacing it.


So DIP1000 won’t become a thing, or it’ll just have a different 
implementation?
Aug 11
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 12/08/2024 8:44 AM, IchorDev wrote:

 On Sunday, 11 August 2024 at 07:11:01 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 The next two weeks is going to be spent on escape analysis, as we're 
 looking at replacing it.


 
 So DIP1000 won’t become a thing, or it’ll just have a different 
 implementation?


Nothing is set in stone currently.

But we are looking into it one way or another.
Aug 11
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/10/2024 10:50 AM, ryuukk_ wrote:

 Why are people scared of walter? he won't eat you,


I might if people came with a side of fava beans and a nice chianti.
Aug 11
prev sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Saturday, 10 August 2024 at 12:26:48 UTC, IchorDev wrote:

 On Saturday, 10 August 2024 at 12:05:31 UTC, ryuukk_ wrote:

 I am a nobody, i can't convince anyone


 Nobody? You??


 Rikki should submit a PR, make it available trhought a 
 -preview, and we move on, at some point we vote and we see how 
 it goes, just like Walter did for bitfields preview


 I think Walter would likely block such a PR. Bitfields can get 
 in that way because it’s Walter’s thing, this is different.


just do it

walter, you'll love it when you'll get to try it ;)
Aug 10
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Saturday, 10 August 2024 at 12:49:18 UTC, ryuukk_ wrote:

 On Saturday, 10 August 2024 at 12:26:48 UTC, IchorDev wrote:

 On Saturday, 10 August 2024 at 12:05:31 UTC, ryuukk_ wrote:

 I am a nobody, i can't convince anyone


 Nobody? You??


 Rikki should submit a PR, make it available trhought a 
 -preview, and we move on, at some point we vote and we see 
 how it goes, just like Walter did for bitfields preview


 I think Walter would likely block such a PR. Bitfields can get 
 in that way because it’s Walter’s thing, this is different.


 just do it

 walter, you'll love it when you'll get to try it ;)



Walter, better ergonomics is one of the reason why people look 
for C++ alternatives

https://x.com/awesomekling/status/1822236888188498031

Make them pick D, or at least make them consider D


Nobody wants to write: `cClass: Character.Class.KNIGHT` or 
`elements: Character.Elements.EARTH | Character.Elements.FIRE`

Make us able to write:

`cClass: .KNIGHT` and `elements: .EARTH | .FIRE`

Named arguments was a great addition, let's continue in that 
direction


DMD is full of short named enums, we both know why ;)
Aug 10
next sibling parent Sergey <kornburn yandex.ru> writes:
On Saturday, 10 August 2024 at 15:41:28 UTC, ryuukk_ wrote:

 Make them pick D, or at least make them consider D


Swift has WASM support and async/await. And their recent 
investment into C++ interop looks promising (D invested more into 
C, than C++).

So for professional development it will be superior:
- Bigger lang developer team
- IT giant support
- More available developers - many people use Swift (even though 
for iOS/macOS)
Aug 10
prev sibling parent reply cc <cc nevernet.com> writes:
On Saturday, 10 August 2024 at 15:41:28 UTC, ryuukk_ wrote:

 Nobody wants to write: `cClass: Character.Class.KNIGHT` or 
 `elements: Character.Elements.EARTH | Character.Elements.FIRE`

 Make us able to write:

 `cClass: .KNIGHT` and `elements: .EARTH | .FIRE`

 Named arguments was a great addition, let's continue in that 
 direction


Yes please thank you.  I'd even lean towards excluding the `.` if 
at all possible but I assume people predict too many potential 
conflicts in other code?  Either way I'd definitely like to see 
this working as a preview, it's a lot easier to see if it Just 
Works or Just Doesn't to try it than to keep it forever locked in 
council session limbo.
Aug 12
parent reply IchorDev <zxinsworld gmail.com> writes:
On Monday, 12 August 2024 at 08:58:59 UTC, cc wrote:

 I'd even lean towards excluding the `.` if at all possible but 
 I assume people predict too many potential conflicts in other 
 code?


It would be too ambiguous. If you write a type-inferred enum 
member that has the same name as a local variable, what happens? 
The fact that there’s more than one answer means that the 
programmer can’t be certain without looking it up; wasting their 
time to use a convenience feature. It’s variable shadowing but 
with types—bleh! Having a prefix makes your intention explicit, 
and later you don’t have to contemplate whether you’re looking at 
a variable/function call, or type inference.


 Either way I'd definitely like to see this working as a 
 preview, it's a lot easier to see if it Just Works or Just 
 Doesn't to try it than to keep it forever locked in council 
 session limbo.


Well you’re welcome to submit a new PR for the existing 
implementation but with it locked behind a preview…
Aug 12
parent reply cc <cc nevernet.com> writes:
On Monday, 12 August 2024 at 11:47:54 UTC, IchorDev wrote:

 It would be too ambiguous. If you write a type-inferred enum 
 member that has the same name as a local variable, what 
 happens? The fact that there’s more than one answer means that 
 the programmer can’t be certain without looking it up; wasting 
 their time to use a convenience feature.


I scold myself for using a local variable named the same as an 
enum member.  s'why I like to use all caps for my enums, saves my 
valuable time so I don't have to look things up ;)
But the compiler already yells at people for ambiguous function 
usage anyway, worst case scenario is you just have it bark 
"assigning symbol x to enum type conflicts with local variable x, 
please use explicit enum reference y.x or cast(y) x to use local 
variable"
Worst worst case scenario is the user has a local variable of the 
same type as the enum itself with the same name as one of the 
enum members in which case he needs to be smacked and made to 
stand in the front of the class for doing something so silly. And 
then cast the local to its own type to force it to compile.


 Well you’re welcome to submit a new PR for the existing 
 implementation but with it locked behind a preview…


Will take me a minute to get up to speed on mucking with the 
compiler but maybe I'll give it a shot next rainy afternoon
Aug 14
next sibling parent cc <cc nevernet.com> writes:
On Wednesday, 14 August 2024 at 13:30:25 UTC, cc wrote:

 But the compiler already yells at people for ambiguous function 
 usage anyway


So I considered it a bit, and here's a scenario I could find 
plausible:

```d
enum SqlResult { ok, error, constraint, } // inferred numeric 
basetype enum

bool ok;
string error;

SqlResult result;
result = constraint; // no problem
result = ok; // Ambiguous assignment to enum: use explicit 
SqlResult.ok, or
              // cast(SqlResult) ok to assign local variable
	result = SqlResult.ok; // explicit enum member
	result = cast(SqlResult) ok; // casts bool to SqlResult
result = error;  // actually, this should be ok, because you 
couldn't cast a string
                  // to a numeric enum anyway, but we could be 
picky about it anyway


SqlResult ok;
SqlResult result;
result = ok; // This is where things get silly. If you do this, 
you did something silly.
              // It could conceivably happen somewhere in a 
billion lines of code, but
              // if it does, the compiler should tell you you're 
silly. No one is going
              // to be sufficiently harmed by being informed that 
this is bad practice
              // and forced to throw in a cast() to make their 
intentions clear.
```
Globals should already be sorted out by existing syntax.  We have 
the "price to pay" of typing in an explicit `Enum.` or 
`cast(Enum)` but this only comes about if we happened to have a 
local variable by the same name as an enum member.  If you just 
don't do that, you aren't stripping yourself of any convenience.  
And if you do, well, what do you want?  The compiler can't read 
your mind ALL the time, but a lot of the time is better than none 
of the time, otherwise we wouldn't have auto, or template 
inference, or a whole bunch of other things.
Aug 14
prev sibling parent reply IchorDev <zxinsworld gmail.com> writes:
On Wednesday, 14 August 2024 at 13:30:25 UTC, cc wrote:

 I scold myself for using a local variable named the same as an 
 enum member.


You and no one else, you do it to yourself.


 Worst worst case scenario is the user has a local variable of 
 the same type as the enum itself with the same name as one of 
 the enum members in which case he needs to be smacked and made 
 to stand in the front of the class for doing something so silly.


And apparently there are no women in the field of computer 
science.


 But the compiler already yells at people for ambiguous function 
 usage anyway, worst case scenario is you just have it bark 
 "assigning symbol x to enum type conflicts with local variable 
 x, please use explicit enum reference y.x or cast(y) x to use 
 local variable"


Now let’s try to use the same syntax for type-inferred struct 
constructors:
```d
MyStruct s = (1, 2, 3);
```
Oh look, a comma expression!
Aug 14
next sibling parent reply user1234 <user1234 12.de> writes:
On Wednesday, 14 August 2024 at 14:43:53 UTC, IchorDev wrote:

 On Wednesday, 14 August 2024 at 13:30:25 UTC, cc wrote:

 [...]


 You and no one else, you do it to yourself.


 [...]


 And apparently there are no women in the field of computer 
 science.


 [...]


 Now let’s try to use the same syntax for type-inferred struct 
 constructors:
 ```d
 MyStruct s = (1, 2, 3);
 ```
 Oh look, a comma expression!


Oh look, a tuple-exp implictly converted using structural typing 
methods. D does not parse the comma-exp anymore.
Aug 14
parent reply IchorDev <zxinsworld gmail.com> writes:
On Wednesday, 14 August 2024 at 15:03:44 UTC, user1234 wrote:

 Now let’s try to use the same syntax for type-inferred struct 
 constructors:
 ```d
 MyStruct s = (1, 2, 3);
 ```
 Oh look, a comma expression!


 Oh look, a tuple-exp implictly converted using structural 
 typing methods.


Hey, cool idea. We’re need to have tuples first, though.


 D does not parse the comma-exp anymore.


So how does this print 3?
```d
import std.stdio;

void main(){
   int n;
   n++, n++, n++;
   writeln(n);
}
```
Aug 14
parent reply user1234 <user1234 12.de> writes:
On Wednesday, 14 August 2024 at 15:23:45 UTC, IchorDev wrote:

 On Wednesday, 14 August 2024 at 15:03:44 UTC, user1234 wrote:

 Now let’s try to use the same syntax for type-inferred struct 
 constructors:
 ```d
 MyStruct s = (1, 2, 3);
 ```
 Oh look, a comma expression!


 Oh look, a tuple-exp implictly converted using structural 
 typing methods.


 Hey, cool idea. We’re need to have tuples first, though.


 D does not parse the comma-exp anymore.


 So how does this print 3?
 ```d
 import std.stdio;

 void main(){
   int n;
   n++, n++, n++;
   writeln(n);
 }
 ```


my bad, I thought it was at least deprecated ;)
Aug 14
parent reply user1234 <user1234 12.de> writes:
On Wednesday, 14 August 2024 at 15:52:08 UTC, user1234 wrote:

 On Wednesday, 14 August 2024 at 15:23:45 UTC, IchorDev wrote:

 On Wednesday, 14 August 2024 at 15:03:44 UTC, user1234 wrote:

 Now let’s try to use the same syntax for type-inferred 
 struct constructors:
 ```d
 MyStruct s = (1, 2, 3);
 ```
 Oh look, a comma expression!


 Oh look, a tuple-exp implictly converted using structural 
 typing methods.


 Hey, cool idea. We’re need to have tuples first, though.


 D does not parse the comma-exp anymore.


 So how does this print 3?
 ```d
 import std.stdio;

 void main(){
   int n;
   n++, n++, n++;
   writeln(n);
 }
 ```


 my bad, I thought it was at least deprecated ;)


I remember now that what is deprecated is to use the result of 
the comma-exp. I just wanna say, off-topic, that if D wants 
tuples, it would be time to fully deprecate the exp, depending on 
if you want tuples in 3 (deprecate now) or 6 years (do nothing 
for now).
Aug 14
next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Wednesday, 14 August 2024 at 16:05:16 UTC, user1234 wrote:

 On Wednesday, 14 August 2024 at 15:52:08 UTC, user1234 wrote:

 On Wednesday, 14 August 2024 at 15:23:45 UTC, IchorDev wrote:

 On Wednesday, 14 August 2024 at 15:03:44 UTC, user1234 wrote:

 Now let’s try to use the same syntax for type-inferred 
 struct constructors:
 ```d
 MyStruct s = (1, 2, 3);
 ```
 Oh look, a comma expression!


 Oh look, a tuple-exp implictly converted using structural 
 typing methods.


 Hey, cool idea. We’re need to have tuples first, though.


 D does not parse the comma-exp anymore.


 So how does this print 3?
 ```d
 import std.stdio;

 void main(){
   int n;
   n++, n++, n++;
   writeln(n);
 }
 ```


 my bad, I thought it was at least deprecated ;)


 I remember now that what is deprecated is to use the result of 
 the comma-exp. I just wanna say, off-topic, that if D wants 
 tuples, it would be time to fully deprecate the exp, depending 
 on if you want tuples in 3 (deprecate now) or 6 years (do 
 nothing for now).


I expect tuple to come before that

It is sad to see D being stuck like that
Aug 14
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 15/08/2024 7:07 AM, ryuukk_ wrote:

 I expect tuple to come before that
 
 It is sad to see D being stuck like that


I've had a brief talk with Timon, he has agreed to do an ideas forum 
post for tuple unpacking in the next week or two. He is very busy.

However he says that its missing parameter list support but otherwise 
implemented.
Aug 15
prev sibling parent reply Nick Treleaven <nick geany.org> writes:
On Wednesday, 14 August 2024 at 16:05:16 UTC, user1234 wrote:

 I remember now that what is deprecated is to use the result of 
 the comma-exp.


Yes.


 I just wanna say, off-topic, that if D wants tuples, it would 
 be time to fully deprecate the exp, depending on if you want 
 tuples in 3 (deprecate now) or 6 years (do nothing for now).


A tuple expression would probably require brackets:
https://forum.dlang.org/post/p3bdp1$2b4e$1 digitalmars.com

A comma expression result can't be used. I think it can only be 
used as an expression statement, or in the `for` *Increment* 
clause. Are there any cases where it could conflict with 
bracketed tuples? dmd accepts a comma expression with  
parentheses, but that would presumably be a 'has no effect' error 
if it was parsed as a tuple.
Aug 14
parent reply user1234 <user1234 12.de> writes:
On Wednesday, 14 August 2024 at 20:37:26 UTC, Nick Treleaven 
wrote:

 On Wednesday, 14 August 2024 at 16:05:16 UTC, user1234 wrote:

 I remember now that what is deprecated is to use the result of 
 the comma-exp.


 Yes.


 I just wanna say, off-topic, that if D wants tuples, it would 
 be time to fully deprecate the exp, depending on if you want 
 tuples in 3 (deprecate now) or 6 years (do nothing for now).


 A tuple expression would probably require brackets:
 https://forum.dlang.org/post/p3bdp1$2b4e$1 digitalmars.com

 A comma expression result can't be used. I think it can only be 
 used as an expression statement, or in the `for` *Increment* 
 clause. Are there any cases where it could conflict with 
 bracketed tuples? [...]


No, I cant see one either. Looks like the comma-exp is actually 
not the blocker ;)
Aug 14
parent reply user1234 <user1234 12.de> writes:
On Wednesday, 14 August 2024 at 20:59:28 UTC, user1234 wrote:

 On Wednesday, 14 August 2024 at 20:37:26 UTC, Nick Treleaven 
 [...]

 A comma expression result can't be used. I think it can only 
 be used as an expression statement, or in the `for` 
 *Increment* clause. Are there any cases where it could 
 conflict with bracketed tuples? [...]


 No, I cant see one either. Looks like the comma-exp is actually 
 not the blocker ;)


Well this was a clumsy way to say "sorry I was wrong". However 
I'm pretty confident about the fact that tuples in D will take 
age to be accepted and implemented. I challenge you to post me an 
email notification when the following will work with an official 
D release:

```d
static assert((0,1,2)[1] + 2 == 3);
```

You can find my email by scrutinizing the messages of the main 
commiter of https://gitlab.com/styx-lang/styx.

Sorry for the supplemental provocation but let's go: I'll try to 
keep the address alive for at least 5 years.

Hope to get a message soon 🤠
Aug 14
parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Thursday, 15 August 2024 at 02:22:58 UTC, user1234 wrote:

 On Wednesday, 14 August 2024 at 20:59:28 UTC, user1234 wrote:

 On Wednesday, 14 August 2024 at 20:37:26 UTC, Nick Treleaven 
 [...]

 A comma expression result can't be used. I think it can only 
 be used as an expression statement, or in the `for` 
 *Increment* clause. Are there any cases where it could 
 conflict with bracketed tuples? [...]


 No, I cant see one either. Looks like the comma-exp is 
 actually not the blocker ;)


 Well this was a clumsy way to say "sorry I was wrong". However 
 I'm pretty confident about the fact that tuples in D will take 
 age to be accepted and implemented. I challenge you to post me 
 an email notification when the following will work with an 
 official D release:

 ```d
 static assert((0,1,2)[1] + 2 == 3);
 ```

 You can find my email by scrutinizing the messages of the main 
 commiter of https://gitlab.com/styx-lang/styx.

 Sorry for the supplemental provocation but let's go: I'll try 
 to keep the address alive for at least 5 years.

 Hope to get a message soon 🤠


send a PR you know how

i'm tired of people capable people doing nothing

whenever i can, i submit a PR, even if it annoys the fuck out of 
me

please, do the same, only that way we'll get native tuples, seems 
people at the top of the D foundation are busy with other matters 
that don't seems to be the language
Aug 15
prev sibling parent reply cc <cc nevernet.com> writes:
On Wednesday, 14 August 2024 at 14:43:53 UTC, IchorDev wrote:

 And apparently there are no women in the field of computer 
 science.


Haha, I was expecting a technical response why my example 
wouldn't work, wasn't expecting gender attacks.  Cool cool, D 
forums gonna be like that then.
Aug 14
parent M. M. <matus email.cz> writes:
On Thursday, 15 August 2024 at 01:33:22 UTC, cc wrote:

 On Wednesday, 14 August 2024 at 14:43:53 UTC, IchorDev wrote:

 And apparently there are no women in the field of computer 
 science.


 Haha, I was expecting a technical response why my example 
 wouldn't work, wasn't expecting gender attacks.  Cool cool, D 
 forums gonna be like that then.


Please, let's not overreact with words like "gender attacks". You 
referred to "a user" by "he", and IchorDev pointed this out 
without any attack. That's all.
Aug 14