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.