Alternative Possibility - Implicit with

Walter Bright newshound2 at digitalmars.com
Sun Nov 20 18:57:20 UTC 2022


On 11/20/2022 8:29 AM, IchorDev wrote:
> On Saturday, 19 November 2022 at 08:49:31 UTC, Walter Bright wrote:
>>
>> Advantages of this scheme:
>>
>> 1. doesn't need the special `$` which people don't seem to like, and using `.` 
>> conflicts with existing use
> 
> I'm up for changing it to something else, like I've said. It's just that I can't 
> think of anything better except maybe `#member`, but I think `#` is reserved right?
> `:member` would be cool but it reminds me of C++ and would be a nightmare in so 
> many cases. `%member` is alright but it looks like an operator. What about 
> `->member`... actually nevermind I hate it.
> `\member`???

So far, I haven't thought of a good syntax for it, either. That's what led me to 
think "what if we don't need the prefix at all".


>> 3. seems to have a natural feel to it
> 
> I have mixed feelings about this. It's *very* hard to intuitively read that it's 
> an enum member when it's written without any kind of affix at all,

There is precedent for it. Fields in non-static member functions do not need a 
`this.` prefix, as there's an implicit `with(this)` for the function.


> and it can't even work with overloaded functions.

Overloaded functions are necessary, but I've often thought they are overused. 
But as I've mentioned in several comments here, the inferred enums lead to 
awkward problems for overload resolution - not just for the compiler, but for 
the user trying to figure out which overload is a better match. C++ overloading 
is so complex that basically nobody understands it - how people figure out which 
is matched is by trial and error, not understanding. While we could come up with 
arbitrary rules to resolve this, I suspect it is not worth it.


> With some changes, I'd consider it.

Good! This discussion thread is very productive.


More information about the Digitalmars-d mailing list