On Wednesday, 23 November 2022 at 23:53:23 UTC, Walter Bright wrote:

Then it's just downright inconsistent.
If you don't want to deal with that, avoid using ETI with heavily overloaded functions. Just like with templates, you pay for what you use.

On Wednesday, 23 November 2022 at 15:24:42 UTC, bachmeier wrote:

You've overlooked my argument that giving two names to the same thing to avoid writing a longer name is a hack. The compiler knows what type you should enter and so do you? Great, don't need to write it.

On Wednesday, 23 November 2022 at 15:24:42 UTC, bachmeier wrote:

This "helpful advice" does not help at all, it's condescending and rude.
Not to mention, your argument is completely reversible. If you don't like ETI because it allows other people to write code that's not verbose enough for you, then find an editor/IDE that displays the types anyway.

On Wednesday, 23 November 2022 at 15:24:42 UTC, bachmeier wrote:

No. $member can only refer to a member of an enum that has to be inferred through context. Like the type of a function parameter, or the type of a struct field.

enum A{ a,b,c,d }
enum B{ a,b,c,d }

struct S{ A one; B two; }

void myFn(A param);

void main(){
    myFn($a); // passes A.a

    S myS = S($c, $d); //myS = S(A.c, B.d);
    myS.one = $b;      //myS = S(A.b, B.d);
}

On Wednesday, 23 November 2022 at 15:24:42 UTC, bachmeier wrote:

If the explicit name is a local alias that doesn't match what they expect when using a library, causing them to search the documentation for the library, and not for a local alias to something from that library then yes, it is going to waste their time.

That's a big issue with reading aliases: that they're identical to a non-aliased type name, and are generally treated the same way by programmers and the compiler.
ETI replaces the type identifier with a unique unary operator, so you can know that you don't know the type.

On Tuesday, 22 November 2022 at 09:37:43 UTC, bauss wrote:

.identifier has a multitude of issues, actually.
Doing this crazy "just ignore ETI if it coincides with module scope operator" idea was one I had before I wrote the DIP. It's clever, but it has a few major flaws.

1. Performance. Every time you try to use ETI, you're also triggering a module-scope lookup every time you compile your code. How would you know something like that without being told?
2. Intuitiveness. Nobody would understand this behaviour without a brief history lesson and a thorough explanation of how module vs. local vs. external variable lookup works. That might sound pretty simple to you, but to a new programmer that is a cluster-headache worth of information to take into account... just to use a shortcut.
3. Flexibility. Oops, did you just name a module-level variable "water"? Well, now you can't use ETI on the "water" member of your "Elements" enum! Why is that? Because we decided to try and fit two features into one operator. :)
4. Future expansion. Fitting two features into .identifier leaves type inference very little room for future expansion. Considering the other 3 issues, I think it would kill any possibility of type inference being added for other language features.

$identifier is less complicated, which is part of how it's most of the way through being implemented already.

On Thursday, 24 November 2022 at 14:36:26 UTC, IchorDev wrote:

$identifier is ugly IMHO and anything that requires any new operators is just not worth it.

As I stated before then I am against this DIP.

The feature isn't that important that I want code to be cluttered with new syntax that hardly adds anything.

On Wednesday, 23 November 2022 at 22:16:35 UTC, Guillaume Piolat wrote:

It's exactly the other way IMO -- whether the feature gets in at all, and the technical considerations of it are more important. As a programmer, whether the syntax will be $identifier, .identifier, _.identifier, $.identifier, #identifier, #.identifier, or something else is secondary. We can of course debate which of these looks the best, but disagreements of taste on questions like that should not block the DIP.

There is only so much free time to spend on writing and implementing DIPs so let's not increase the bar by vetoing on grounds like this.

You're demanding .identifier for a better reason - that is, avoiding reserving any new syntax. I don't agree with that either, but at least it's a technical argument as opposed to mere bikeshedding. So I'm not singling you two with what I wrote above, instead I'm aiming at this thread in general.

On Friday, 25 November 2022 at 09:53:34 UTC, Dukc wrote:

Syntax aesthetics play a big part in language design. Also alignment with other popular languages is also an argument.

Yes, if the syntax of a new feature looks like a behind of camel, then it is better that the feature is postponed.

On Tuesday, 22 November 2022 at 04:17:37 UTC, IchorDev wrote:

I think only if someone named a variable _. That does not seem a sensible variable name to use and any breakage of that is justified IMO. I know it's sometimes used as a function name for translations - though because that requires an argument I think that distinguishes it from possible use for ETI.

The nice thing about this syntax (ironically) is it's already an expression so:

1. it's more intuitive than using a new sigil. It looks like accessing a member of something, which it is. Underscore is often used in other languages to mean don't care, i.e. infer the parent type. (In cppfront you can use underscore instead of a function parameter type and the type will be inferred).

2. We aren't using up any syntax or reserving a sigil for this feature so there's more syntax available for any future features.

On Friday, 25 November 2022 at 19:40:35 UTC, Nick Treleaven wrote:

Right on.

But... Why then not not go one step further, and leave it up to each one's private code to

alias _ = EType;

when desired, and leave the language and backwards compatibility alone?

On Friday, 25 November 2022 at 19:40:35 UTC, Nick Treleaven wrote:

$_ is the default variable in perl (or was). I can potentially envision people using _ as an iterator, match result, bitfield padding variable, etc. Whether that's a big enough issue worth worrying about, eh. Though it does seem odd have to make the exception "_ is a word character, you can use it in any symbol name, except by itself." Suppose that's essentially the same situation for keywords, though.

Is .. used anywhere besides slicing and foreach? Just throwing that onto the pile, though it's probably another tool-breaker.

On Saturday, 26 November 2022 at 11:14:05 UTC, XavierAP wrote:

alias _ = EType;

Then you just have more escalating noise around every location where such aliases are needed. Having to copy/paste:

alias A = AttackType;
alias W = WeaponType;
alias M = MovementType;

is unideal. And the broader the scope they're declared in the more likely they are to conflict with other shortened alias names.

And then when you have, say enum EntityState and enum EnemySprite, what then? alias ETS, alias ESPR... just further increasing symbolic clutter and cognitive load.