Re: Unexplainable behaviour with direct struct assignment.

[Tejas via Digitalmars-d-learn]

On Wednesday, 18 May 2022 at 21:52:18 UTC, HuskyNator wrote:

On Wednesday, 18 May 2022 at 21:49:14 UTC, HuskyNator wrote:
After updating to `DMD 2.100.0` & `DUB 1.29.0`, I still get 
this behavior.
Only when I use `dub run --b=debug` however (default for me). 
`dub run --b=release` does return what one would expect.


I don't know if this matters either, but I'm using windows 10 
(64 bits).


Does this happen with LDC as well?

Re: class destructors must be @disabled?

[Steven Schveighoffer via Digitalmars-d-learn]

On 5/18/22 3:58 PM, Ali Çehreli wrote:


Hmm. Perhaps the guideline should be "all destructors must be @nogc".


That one I agree with.

-Steve

Re: Unexplainable behaviour with direct struct assignment.

[HuskyNator via Digitalmars-d-learn]

On Wednesday, 18 May 2022 at 21:49:14 UTC, HuskyNator wrote:
After updating to `DMD 2.100.0` & `DUB 1.29.0`, I still get 
this behavior.
Only when I use `dub run --b=debug` however (default for me). 
`dub run --b=release` does return what one would expect.


I don't know if this matters either, but I'm using windows 10 (64 
bits).

Re: Unexplainable behaviour with direct struct assignment.

[HuskyNator via Digitalmars-d-learn]

On Wednesday, 18 May 2022 at 20:16:51 UTC, Dennis wrote:

On Wednesday, 18 May 2022 at 20:05:05 UTC, HuskyNator wrote:

This will print:
```
0
50
nan
```


Which compiler and flags are you using? For me it just prints 
50, you might be stumbling on some (old) bugs in the DMD 
backend with floating point registers. Examples of such bugs 
are:


https://issues.dlang.org/show_bug.cgi?id=18573
https://issues.dlang.org/show_bug.cgi?id=22163


I've been using `DMD 2.098.0` using a default DUB (1.27.0) init 
project (I'm not quite sure what the compile flags are).


After updating to `DMD 2.100.0` & `DUB 1.29.0`, I still get this 
behavior.
Only when I use `dub run --b=debug` however (default for me). 
`dub run --b=release` does return what one would expect.

Re: Installing DMD on linux via snap

[Jordi Sayol via Digitalmars-d-learn]

El 18/5/22 a les 17:24, matheus via Digitalmars-d-learn ha escrit:


Yesterday I needed to install DMD on a fresh installed version of Linux, so 
since I was using Xubuntu I decided to use snap.





$ sudo wget https://master.dl.sourceforge.net/project/d-apt/files/d-apt.list -O 
/etc/apt/sources.list.d/d-apt.list

$ sudo apt update --allow-insecure-repositories && sudo apt -y --allow-unauthenticated 
install --reinstall d-apt-keyring && sudo apt update

then just install:

$ sudo apt install dmd-compiler dmd-tools dmd-doc dub

Re: vibe.d ubuntu 22.04 ssl linking error

[Gavin Gray via Digitalmars-d-learn]

On Wednesday, 18 May 2022 at 20:41:53 UTC, Gavin Gray wrote:
After upgrading to ubuntu 22.04, I get the linker error below 
for a project that previously built successfully.


OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

LDC - the LLVM D compiler (1.27.1):
  based on DMD v2.097.2 and LLVM 12.0.1
  built with LDC - the LLVM D compiler (1.27.1)
  Default target: x86_64-unknown-linux-gnu
  Host CPU: skylake
  http://dlang.org - http://wiki.dlang.org/LDC

vibe-d-0.9.5-beta.1

I tried unsuccessfully to also install an earlier version of 
OpenSSL


Any suggestions?

Compiling Diet HTML template test.dt...
Linking...
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:284: 
error: undefined reference to 'SSL_get_peer_certificate'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:625: 
error: undefined reference to 'SSLv23_client_method'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:626: 
error: undefined reference to 'SSLv23_client_method'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:630: 
error: undefined reference to 'SSLv23_client_method'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:631: 
error: undefined reference to 'SSLv23_client_method'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:638: 
error: undefined reference to 'SSLv23_server_method'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:639: 
error: undefined reference to 'SSLv23_server_method'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:641: 
error: undefined reference to 'SSLv23_server_method'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:642: 
error: undefined reference to 'SSLv23_server_method'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:906: 
error: undefined reference to 'get_rfc3526_prime_2048'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:1100: 
error: undefined reference to 'SSL_load_error_strings'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:1101: 
error: undefined reference to 'SSL_library_init'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:1103: 
error: undefined reference to 'CRYPTO_num_locks'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:: 
error: undefined reference to 'CRYPTO_set_id_callback'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:1112: 
error: undefined reference to 'CRYPTO_set_locking_callback'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:1117: 
error: undefined reference to 'SSL_get_ex_new_index'
home/gavin/.dub/packages/openssl-1.1.6_1.0.1g/openssl/deimos/openssl/safestack.d:140:
 error: undefined reference to 'sk_num'
home/gavin/.dub/packages/openssl-1.1.6_1.0.1g/openssl/deimos/openssl/safestack.d:142:
 error: undefined reference to 'sk_value'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:1380: 
error: undefined reference to 'ERR_put_error'
collect2: error: ld returned 1 exit status
Error: /usr/bin/cc failed with status: 1
/home/gavin/dlang/ldc-1.27.1/bin/ldc2 failed with exit code 1.


After posting I noticed the actual version of vibe was 0.9.4. 
Upgraded to vibe 0.9.5.beta.1 and now it linked successfully.


Therefore no longer an issue!

vibe.d ubuntu 22.04 ssl linking error

[Gavin Gray via Digitalmars-d-learn]

After upgrading to ubuntu 22.04, I get the linker error below for 
a project that previously built successfully.


OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

LDC - the LLVM D compiler (1.27.1):
  based on DMD v2.097.2 and LLVM 12.0.1
  built with LDC - the LLVM D compiler (1.27.1)
  Default target: x86_64-unknown-linux-gnu
  Host CPU: skylake
  http://dlang.org - http://wiki.dlang.org/LDC

vibe-d-0.9.5-beta.1

I tried unsuccessfully to also install an earlier version of 
OpenSSL


Any suggestions?

Compiling Diet HTML template test.dt...
Linking...
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:284: 
error: undefined reference to 'SSL_get_peer_certificate'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:625: 
error: undefined reference to 'SSLv23_client_method'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:626: 
error: undefined reference to 'SSLv23_client_method'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:630: 
error: undefined reference to 'SSLv23_client_method'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:631: 
error: undefined reference to 'SSLv23_client_method'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:638: 
error: undefined reference to 'SSLv23_server_method'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:639: 
error: undefined reference to 'SSLv23_server_method'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:641: 
error: undefined reference to 'SSLv23_server_method'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:642: 
error: undefined reference to 'SSLv23_server_method'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:906: 
error: undefined reference to 'get_rfc3526_prime_2048'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:1100: 
error: undefined reference to 'SSL_load_error_strings'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:1101: 
error: undefined reference to 'SSL_library_init'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:1103: 
error: undefined reference to 'CRYPTO_num_locks'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:: 
error: undefined reference to 'CRYPTO_set_id_callback'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:1112: 
error: undefined reference to 'CRYPTO_set_locking_callback'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:1117: 
error: undefined reference to 'SSL_get_ex_new_index'
home/gavin/.dub/packages/openssl-1.1.6_1.0.1g/openssl/deimos/openssl/safestack.d:140:
 error: undefined reference to 'sk_num'
home/gavin/.dub/packages/openssl-1.1.6_1.0.1g/openssl/deimos/openssl/safestack.d:142:
 error: undefined reference to 'sk_value'
home/gavin/.dub/packages/vibe-d-0.9.4/vibe-d/tls/vibe/stream/openssl.d:1380: 
error: undefined reference to 'ERR_put_error'
collect2: error: ld returned 1 exit status
Error: /usr/bin/cc failed with status: 1
/home/gavin/dlang/ldc-1.27.1/bin/ldc2 failed with exit code 1.

Re: Unexplainable behaviour with direct struct assignment.

[Dennis via Digitalmars-d-learn]

On Wednesday, 18 May 2022 at 20:05:05 UTC, HuskyNator wrote:

This will print:
```
0
50
nan
```


Which compiler and flags are you using? For me it just prints 50, 
you might be stumbling on some (old) bugs in the DMD backend with 
floating point registers. Examples of such bugs are:


https://issues.dlang.org/show_bug.cgi?id=18573
https://issues.dlang.org/show_bug.cgi?id=22163

Re: Unexplainable behaviour with direct struct assignment.

[H. S. Teoh via Digitalmars-d-learn]

On Wed, May 18, 2022 at 08:05:05PM +, HuskyNator via Digitalmars-d-learn 
wrote:
[...]
> ```d
> module app;
> import std.stdio;
> 
> struct A {
>   float[1] vec;
>   this(float[1] n) {
>   this.vec = n;
>   }
> }
> 
> void main(string[] args) {
>   A c = A([50.0f]);
>   writeln(c.vec[0]);
> 
>   A b = A([50.0f]);
>   writeln(b.vec[0]);
> 
>   c = A([50.0f]);
>   writeln(c.vec[0]);
> }
> ```
> 
> This will print:
> ```
> 0
> 50
> nan
> ```
[...]

Can't replicate this problem. On my local machine (Linux/64), I get the
output:


50
50
50


What's the exact compile command you're using?


T

-- 
To err is human; to forgive is not our policy. -- Samuel Adler

Unexplainable behaviour with direct struct assignment.

[HuskyNator via Digitalmars-d-learn]

I came across strange, seemingly non-deterministic, behaviour 
today. I simplified it the best I could below. I entice you to 
run the following piece of code.


```d
module app;
import std.stdio;

struct A {
float[1] vec;
this(float[1] n) {
this.vec = n;
}
}

void main(string[] args) {
A c = A([50.0f]);
writeln(c.vec[0]);

A b = A([50.0f]);
writeln(b.vec[0]);

c = A([50.0f]);
writeln(c.vec[0]);
}
```

This will print:
```
0
50
nan
```

My findings:
- The first initializer will always contain 0
- Initialization to another variable will yield the expected 50
- Reinitialization will always yield null

Am I missing something? Is this a bug? I have no idea what is 
wrong.

Thanks for you help,
- HN

Re: class destructors must be @disabled?

[Ali Çehreli via Digitalmars-d-learn]

On 5/18/22 12:45, Steven Schveighoffer wrote:

> Not cleaning it up because you're afraid of destructors is not the 
answer.


Fine. The GC allocation issue remains. It looks like one of the 
following should be observed:


a) @disable ~this() for all classes so that we are safe from the 
destructors of otherwise-well-written struct members as well. In 
general, this option requires a cleanup function for the class, which 
should be called at an opportune moment before its memory is freed by 
the GC.


b) Consider GC.inFinalizer() in every struct destructor that has any 
chance of being used in a class. This may not work for all structs (see 
below).


c) Extend the "do not allocate GC memory in the destructor" guideline to 
all structs.


Do not allocate memory in such conditions, which may be problematic 
because my example would make every struct object expensive by holding 
on to a string prepared before hand to be used in the destructor:


struct S {
  int id;
  string closingMessage;   // <-- Expensive

  this(int id) {
this.id = id;
this.closingMessage = format!"%s signing off"(id);
  }

  ~this() {
// No allocation in the destructor; good.
closeConnection(closingMessage);
  }
}

The non-expensive solution is to use a @nogc solution like sprintf?

Hmm. Perhaps the guideline should be "all destructors must be @nogc".

Ali

Re: class destructors must be @disabled?

[Steven Schveighoffer via Digitalmars-d-learn]

On 5/18/22 2:58 PM, H. S. Teoh wrote:

On Wed, May 18, 2022 at 02:35:00PM -0400, Steven Schveighoffer via 
Digitalmars-d-learn wrote:
[...]

No. Class destructors are for cleaning up non-GC resources. As long as
you stick to those, you can safely run them.

Structs that get put into classes have to run their destructors
properly, otherwise, you will have horrible inconsistencies.

For instance, I would not want to disable the destruction of a
RefCounted struct inside a class.

[...]

So if the user runs your program with --DRT-gcopt=cleanup:none and you
happen to have a RefCounted struct inside a GC-allocated class, then
you're screwed?


I approach it from a different way. Let's say I'm writing a File class, 
and it has a file descriptor inside it.


It's not me that's deciding when to clean up the object. All I want to 
do as the *library author* is to clean up the resource *I* opened, when 
someone is cleaning my object up. In other words, I don't care how you 
destroy it, GC, synchronously, etc, when you clean up the class 
instance, I will clean up my mess. That's just good lifetime management.


Not cleaning it up because you're afraid of destructors is not the answer.

That being said, I think it's a reasonable position for you to not 
support running your program with that DRT option (obviously, we do rely 
on the GC to clean up some things).


-Steve

Re: class destructors must be @disabled?

[Ali Çehreli via Digitalmars-d-learn]

On 5/18/22 11:35, Steven Schveighoffer wrote:

> Structs that get put into classes have to run their destructors
> properly, otherwise, you will have horrible inconsistencies.

Does that suggest a different guideline: "Careful with structs in 
classes." That goes against orthogonality (independence). I should not 
care where a struct type is used. Or, the way to use it properly should 
be handled by the struct. (Continuing below.)


> You can use the GC.inFinalizer to check if you are concerned about using
> the GC in your struct dtors.

Is that the guideline for most usability then? struct destructors must 
check for GC.inFinalizer because they may be used in a class. This 
doesn't sound useful either.


Perhaps my struct example should have allocated the "farewell" string 
before the destructor. And then this renders struct destructors almost 
like class destructors: Don't allocate in the destructor.


Something is fishy here. :)

Ali

Re: class destructors must be @disabled?

[H. S. Teoh via Digitalmars-d-learn]

On Wed, May 18, 2022 at 02:35:00PM -0400, Steven Schveighoffer via 
Digitalmars-d-learn wrote:
[...]
> No. Class destructors are for cleaning up non-GC resources. As long as
> you stick to those, you can safely run them.
> 
> Structs that get put into classes have to run their destructors
> properly, otherwise, you will have horrible inconsistencies.
> 
> For instance, I would not want to disable the destruction of a
> RefCounted struct inside a class.
[...]

So if the user runs your program with --DRT-gcopt=cleanup:none and you
happen to have a RefCounted struct inside a GC-allocated class, then
you're screwed?


T

-- 
Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel

Re: class destructors must be @disabled?

[H. S. Teoh via Digitalmars-d-learn]

On Wed, May 18, 2022 at 11:02:01AM -0700, Ali Çehreli via Digitalmars-d-learn 
wrote:
[...]
> HORROR:
> 
> Now, a big one that I've just realized.
> 
> - The two guidelines above (the "don't touch class members" one and
> the "don't allocate" one) miss an important fact that they apply
> recursively even to struct members of classes. For example, structs
> that are used as members of a class cannot allocate memory in their
> destructors either.
[...]
> Of course, we still should and do have the power to shape our programs
> any way we want but I think '@disable ~this();' should be added to
> classes as a general rule unless the programmer knows it will work
> otherwise.
[...]

I remember years ago, Andrei proposed that we remove class dtors (or
finalizers, whatever) from the language altogether.  That may be a bit
extreme, but it reflects the general idea you wrote here.

One observation about class dtors is, if they're useless for cleaning up
resources (since we can't rely on them being run at all, and we're not
allowed to touch anything referenced by the class that may have already
been collected by the GC, and we're not allowed to do anything that may
trigger a GC allocation), then *what practical use do they serve at
all*?!  At this point they're just some vestigial construct that are not
useful for all practical intents and purposes anymore.

The one big caveat, of course, is emplaced classes and classes whose
allocation is being managed by something other than the (default) GC. If
a class is stack-allocated, for example, the dtor could meaningfully do
something useful like free resources upon going out of scope.  IOW,
class dtors are useless by default, and only useful in non-default
usage. :-P


T

-- 
Obviously, some things aren't very obvious.

Re: class destructors must be @disabled?

[Steven Schveighoffer via Digitalmars-d-learn]

On 5/18/22 2:02 PM, Ali Çehreli wrote:

Of course, we still should and do have the power to shape our programs 
any way we want but I think '@disable ~this();' should be added to 
classes as a general rule unless the programmer knows it will work 
otherwise.


What do you think?


No. Class destructors are for cleaning up non-GC resources. As long as 
you stick to those, you can safely run them.


Structs that get put into classes have to run their destructors 
properly, otherwise, you will have horrible inconsistencies.


For instance, I would not want to disable the destruction of a 
RefCounted struct inside a class.


You can use the GC.inFinalizer to check if you are concerned about using 
the GC in your struct dtors.


-Steve

class destructors must be @disabled?

[Ali Çehreli via Digitalmars-d-learn]

I am writing these in view of class objects commonly being constructed 
as GC-owned objects.


GUIDELINES:

We've seen the following points mentioned in these forums.

- (This one is just a complication.) Classes don't have destructors 
anyway; they should be called finalizers.


- Don't allocate memory from the GC in a class destructor. (For example, 
writeln may be fine with simple types but writefln or format would not be.)


- Don't touch any GC-owned member in a class destructor because that 
member may have already been finalized.


SOME FACTS:

- Class destructors are not guarenteed to be executed. And this cannot 
be controlled by the programmer. For example, the user of the program 
can pass the following command line option and the GC will not execute 
class destructors:


  $ myprogram "--DRT-gcopt=cleanup:none" ...

(The following example will run fine when started that way.)

- Even if the destructor is executed by the GC, when it is executed 
exactly is naturally unspecified ("sometime in the future"). For that 
reason, it does not make sense to leave important responsibilities to 
class destructors like closing a File. Not only the file may not be 
closed, you may be exceeding resources that the OS provides by holding 
on to them for too long.


HORROR:

Now, a big one that I've just realized.

- The two guidelines above (the "don't touch class members" one and the 
"don't allocate" one) miss an important fact that they apply recursively 
even to struct members of classes. For example, structs that are used as 
members of a class cannot allocate memory in their destructors either.


The following program ends with core.exception.InvalidMemoryOperationError:

import std.format;

void closeConnection(string s) {
}

struct S {
  int id;

  ~this() {
closeConnection(format!"%s signing off"(id));
  }
}

class C {
  S s;

  this(int id) {
s = S(id);
  }

  // @disable ~this();
}

void main() {
  // Just 1 is sufficient to show the error in Ali's environment.
  enum N = 1;
  foreach (i; 0 .. N) {
auto c = new C(i);
  }
}

Note how the struct is written in good faith and the class is obeying 
all the guidelines (by not even defining a destructor). I think the 
problem is the missed guideline that is on the subject line: classes 
should @disable their destructors. The program above will work fine when 
that line is uncommented.


Of course, we still should and do have the power to shape our programs 
any way we want but I think '@disable ~this();' should be added to 
classes as a general rule unless the programmer knows it will work 
otherwise.


What do you think?

Ali

Re: Installing DMD on linux via snap

[Alain De Vos via Digitalmars-d-learn]

You could try on linux,
apt-cache search dmd
apt-cache search ldc
apt-cache search ldc2

Re: I need to use delete as the method name. But now it's still a keyword, right?

[zoujiaqing via Digitalmars-d-learn]

On Wednesday, 18 May 2022 at 15:33:09 UTC, Steven Schveighoffer 
wrote:

On 5/18/22 2:13 AM, bauss wrote:

On Wednesday, 18 May 2022 at 02:12:42 UTC, zoujiaqing wrote:

https://dlang.org/changelog/2.100.0.html#deprecation_delete

My code:

```D
import std.stdio;

class HttpClient
{
string get(string url)
{
    return "";
}

string delete(string url)
{
    return "";
}
}

void main()
{
auto http = new HttpClient;

string content = 
http.get("https://forum.dlang.org/group/general;);
string content = 
http.delete("https://forum.dlang.org/newpost/general?;);

}
```

error message
```bash
% dub build --compiler=dmd
Performing "debug" build using dmd for x86_64.
test ~master: building configuration "application"...
source/app.d(10,9): Error: no identifier for declarator 
`string`

source/app.d(10,9): Error: declaration expected, not `delete`
source/app.d(14,1): Error: unmatched closing brace
dmd failed with exit code 1.
```

I wonder when I can use it. Because this will cause a 
software naming problem.


Considering the deprecation period has ended then IMO it 
should be able to be used as an identifier.


I would consider this a bug.


No, it's intentional.

https://dlang.org/changelog/2.100.0.html#deprecation_delete

> Starting with this release, using the delete *keyword* will
result in a *compiler error*.

It's still a keyword according to that. I'm assuming a future 
release will remove the error, and then you can use it as a 
symbol.


-Steve


The body is now available, and hopefully the delete keyword will 
be deprecated soon.

Re: Installing DMD on linux via snap

[matheus via Digitalmars-d-learn]

On Wednesday, 18 May 2022 at 15:27:57 UTC, rikki cattermole wrote:

Snap package source: https://github.com/dlang-snaps/dmd.snap/

Hasn't been updated in 3 years.


I see... and even that I found my answer elsewhere, this problem 
was already discussed there: 
https://github.com/dlang-snaps/dmd.snap/issues (GCC isn't part of 
the dependencies).


But there was no further progress.

Matheus.

Re: I need to use delete as the method name. But now it's still a keyword, right?

[Steven Schveighoffer via Digitalmars-d-learn]

On 5/18/22 2:13 AM, bauss wrote:

On Wednesday, 18 May 2022 at 02:12:42 UTC, zoujiaqing wrote:

https://dlang.org/changelog/2.100.0.html#deprecation_delete

My code:

```D
import std.stdio;

class HttpClient
{
string get(string url)
{
    return "";
}

string delete(string url)
{
    return "";
}
}

void main()
{
auto http = new HttpClient;

string content = http.get("https://forum.dlang.org/group/general;);
string content = 
http.delete("https://forum.dlang.org/newpost/general?;);

}
```

error message
```bash
% dub build --compiler=dmd
Performing "debug" build using dmd for x86_64.
test ~master: building configuration "application"...
source/app.d(10,9): Error: no identifier for declarator `string`
source/app.d(10,9): Error: declaration expected, not `delete`
source/app.d(14,1): Error: unmatched closing brace
dmd failed with exit code 1.
```

I wonder when I can use it. Because this will cause a software naming 
problem.


Considering the deprecation period has ended then IMO it should be able 
to be used as an identifier.


I would consider this a bug.


No, it's intentional.

https://dlang.org/changelog/2.100.0.html#deprecation_delete

> Starting with this release, using the delete *keyword* will result in 
a *compiler error*.


It's still a keyword according to that. I'm assuming a future release 
will remove the error, and then you can use it as a symbol.


-Steve

Re: Installing DMD on linux via snap

[rikki cattermole via Digitalmars-d-learn]

Snap package source: https://github.com/dlang-snaps/dmd.snap/

Hasn't been updated in 3 years.

Installing DMD on linux via snap

[matheus via Digitalmars-d-learn]

Hi,

Even my problem is already solved, I'm passing this information 
because I don't know if you are aware.


Yesterday I needed to install DMD on a fresh installed version of 
Linux, so since I was using Xubuntu I decided to use snap.


sudo snap install dmd

Then a warning appeared saying that because some permissions I 
should add --classic, OK I added and the installation proceeded.


So I just ran DMD alone and I got the version and some info, but 
when I tried to compile a simple Hello world to check if 
everything was really fine, I was greeted with this:


cc: No such file or directory
--- errorlevel 255

Looking online I found my answer, this was probably because it 
was missing GCC, then I did:


apt-get install build-essential

And after that it worked, but I wonder... couldn't we get a hint 
about this after or even before installing DMD?


I remember installing other applications and being asked to 
install additional libraries/packages. Couldn't we have the same?


Matheus.

Re: I need to use delete as the method name. But now it's still a keyword, right?

[zoujiaqing via Digitalmars-d-learn]

On Wednesday, 18 May 2022 at 06:13:45 UTC, bauss wrote:


Considering the deprecation period has ended then IMO it should 
be able to be used as an identifier.


I would consider this a bug.


I hope this is a bug ;)

Re: Why are structs and classes so different?

[forkit via Digitalmars-d-learn]

On Sunday, 15 May 2022 at 21:33:24 UTC, Ali Çehreli wrote:


I still think my answer is the real one. My implied question 
remains: Why does C++ have struct and class disticnction? I 
know they have different default access specifications but does 
that warrant two kinds?




Here is a very interesting article that researches this subject.

https://belaycpp.com/2021/09/17/history-of-c-explanation-on-why-the-keyword-class-has-no-more-reason-to-exist/

Re: I need to use delete as the method name. But now it's still a keyword, right?

[bauss via Digitalmars-d-learn]

On Wednesday, 18 May 2022 at 02:12:42 UTC, zoujiaqing wrote:

https://dlang.org/changelog/2.100.0.html#deprecation_delete

My code:

```D
import std.stdio;

class HttpClient
{
string get(string url)
{
return "";
}

string delete(string url)
{
return "";
}
}

void main()
{
auto http = new HttpClient;

	string content = 
http.get("https://forum.dlang.org/group/general;);
	string content = 
http.delete("https://forum.dlang.org/newpost/general?;);

}
```

error message
```bash
% dub build --compiler=dmd
Performing "debug" build using dmd for x86_64.
test ~master: building configuration "application"...
source/app.d(10,9): Error: no identifier for declarator `string`
source/app.d(10,9): Error: declaration expected, not `delete`
source/app.d(14,1): Error: unmatched closing brace
dmd failed with exit code 1.
```

I wonder when I can use it. Because this will cause a software 
naming problem.


Considering the deprecation period has ended then IMO it should 
be able to be used as an identifier.


I would consider this a bug.

Re: Question on shapes

[JG via Digitalmars-d-learn]

On Tuesday, 17 May 2022 at 00:10:55 UTC, Alain De Vos wrote:
Let's say a shape is ,a circle with a radius ,or a square with 
a rectangular size.
I want to pass shapes to functions, eg to draw them on the 
screen,

draw(myshape) or myshape.draw();
But how do i implement best shapes ?


You could also do something like:
```d
import std;

struct Circle {
double radius;
void draw() {
writeln(format!"Draw a circle of radius %s"(radius));
}
}

struct Rectangle {
double width;
double height;
 void draw() {
writeln(format!"Draw a rectangle of width %s and height 
%s."(width,height));

}
}

alias Shape = SumType!(Circle,Rectangle);


void main() {
  Shape[] shapes = [Shape(Rectangle(2.0,3.)),Shape(Circle(3.0))];

  foreach(shape; shapes) { shape.match!(x=>x.draw); }
}
```

or

```d
import std;

struct Circle {
double radius;
}

struct Rectangle {
double width;
double height;
}

alias Shape = SumType!(Circle,Rectangle);

struct Drawer {
int drawerState;
void drawShape(Shape shape) {
shape.match!(x=>drawShape(x));
}
void drawShape(Circle circle) {
writeln(format!"Draw a circle of radius 
%s"(circle.radius));

}
void drawShape(Rectangle rectangle) {
writeln(format!"Draw a rectangle of width %s and height 
%s."(rectangle.width,rectangle.height));

}
}

void main() {
  Shape[] shapes = [Shape(Rectangle(2.0,3.)),Shape(Circle(3.0))];
  Drawer d;
  foreach(shape; shapes) { d.drawShape(shape); }
}
```