Re: Beerconf April 2023
On 4/27/23 2:17 PM, Sergey wrote: On Thursday, 27 April 2023 at 17:42:30 UTC, Steven Schveighoffer wrote: On 4/16/23 11:39 AM, Steven Schveighoffer wrote: # BEERCONF! Beerconf for April is happening 2 weeks from now, on the 29-30. A reminder that this is happening in 2 days! ## Presentations? This beerconf, we have another presentation! Hipreme will show off the HipremeEngine build system: Cross compiling D for Android, WebAssembly, MacOS, and any new future platform in any host environment, with 0 manual configuration : How HipremeEngine solves that problem without any kind of initial setup (even for non D users) The time for this will be 17:30 Sunday, April 30 Awesome! Could you please specify the time zone.. CET, GMT, UTC? Oof, totally forgot that. It's UTC. Thanks! -Steve
Re: Beerconf April 2023
On Thursday, 27 April 2023 at 17:42:30 UTC, Steven Schveighoffer wrote: On 4/16/23 11:39 AM, Steven Schveighoffer wrote: # BEERCONF! Beerconf for April is happening 2 weeks from now, on the 29-30. A reminder that this is happening in 2 days! ## Presentations? This beerconf, we have another presentation! Hipreme will show off the HipremeEngine build system: Cross compiling D for Android, WebAssembly, MacOS, and any new future platform in any host environment, with 0 manual configuration : How HipremeEngine solves that problem without any kind of initial setup (even for non D users) The time for this will be 17:30 Sunday, April 30 See you all there! -Steve Awesome! Could you please specify the time zone.. CET, GMT, UTC?
Re: Beerconf April 2023
On 4/16/23 11:39 AM, Steven Schveighoffer wrote: # BEERCONF! Beerconf for April is happening 2 weeks from now, on the 29-30. A reminder that this is happening in 2 days! ## Presentations? This beerconf, we have another presentation! Hipreme will show off the HipremeEngine build system: Cross compiling D for Android, WebAssembly, MacOS, and any new future platform in any host environment, with 0 manual configuration : How HipremeEngine solves that problem without any kind of initial setup (even for non D users) The time for this will be 17:30 Sunday, April 30 See you all there! -Steve
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Thursday, 27 April 2023 at 06:10:57 UTC, Basile B. wrote:
It's a misconception of the problem that the DIP tried to
solve. What the DIP tried to solve is that the compiler should
know that you are using an enum member. Actually I even think
this should work without any special syntax, as a "last
resort", let's say. But as you've explained, through Mike's
report, this causes problems for D because the identifier
resolution is tied to a particular implementation, i.e your
fast symtabs.
I don't think it's a misconception. It's more like a complete
lack of clarity. What would be the point of complexifying the
language for the new programmer when you can just use an
anonymous enum? This program runs just fine:
```
import std.stdio;
enum {
A1,
B1,
C1,
D1
}
enum {
_A,
_B,
_C,
_D
}
void main() {
writeln(A1);
writeln(_A);
writeln(A1 == _A);
auto flag = _B;
switch(flag) {
case _A:
writeln("_A");
break;
case _B:
writeln("_B");
break;
case _C:
writeln("_C");
break;
case _D:
writeln("_D");
break;
default:
break;
}
}
```
What's the point in using a named enum if you want an anonymous
enum? The response when this question was asked was not "because
[something where it matters]". It was instead to ignore the
question, give an unrealistic example that was solved by the
response, and insert a bunch of unhelpful hostility.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Thursday, 27 April 2023 at 06:10:57 UTC, Basile B. wrote:
On Thursday, 27 April 2023 at 00:16:10 UTC, Walter Bright wrote:
This also works:
alias F = MySuperLongNameFlag;
auto flag = F.A | F.B | F.C | F.D;
set_flags(F.A | F.B | F.C | F.D);
It's similar to setting a local variable to some complex
expression, just so you don't have to repeat that expression
multiple times.
It's a misconception of the problem that the DIP tried to
solve. What the DIP tried to solve is that the compiler should
know that you are using an enum member. Actually I even think
this should work without any special syntax, as a "last
resort", let's say. But as you've explained, through Mike's
report, this causes problems for D because the identifier
resolution is tied to a particular implementation, i.e your
fast symtabs.
I don't think it's a misconception. It's more like a complete
lack of clarity. What would be the point of complexifying the
language for the new programmer when you can just use an
anonymous enum? This program runs just fine:
```
import std.stdio;
enum {
A1,
B1,
C1,
D1
}
enum {
_A,
_B,
_C,
_D
}
void main() {
writeln(A1);
writeln(_A);
writeln(A1 == _A);
auto flag = _B;
switch(flag) {
case _A:
writeln("_A");
break;
case _B:
writeln("_B");
break;
case _C:
writeln("_C");
break;
case _D:
writeln("_D");
break;
default:
break;
}
}
```
What's the point in using a named enum if you want an anonymous
enum? The response when this question was asked was not "because
[something where it matters]". It was instead to ignore the
question, give an unrealistic example that was solved by the
response, and insert a bunch of unhelpful hostility.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Thursday, 27 April 2023 at 00:16:10 UTC, Walter Bright wrote: This also works: alias F = MySuperLongNameFlag; auto flag = F.A | F.B | F.C | F.D; set_flags(F.A | F.B | F.C | F.D); It's similar to setting a local variable to some complex expression, just so you don't have to repeat that expression multiple times. It's a misconception of the problem that the DIP tried to solve. What the DIP tried to solve is that the compiler should know that you are using an enum member. Actually I even think this should work without any special syntax, as a "last resort", let's say. But as you've explained, through Mike's report, this causes problems for D because the identifier resolution is tied to a particular implementation, i.e your fast symtabs.
