6 days ago

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

>

I suggest abandoning the ETI for overloaded functions.

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.

6 days ago

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

>

I also don't agree that naming things is a hack.

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:

>

Then find a better editor/IDE. One that has copy and paste.

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:

>

The DIP proposes using the same $ to refer to any enum.

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 someone is confused by an explicit name, by definition they're going to be confused by a generic $.

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.

6 days ago

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

>

If it's not implemented with .identifier then I will oppose it.

I don't buy the "it will break code" point of view either.

[...] if you type .a then it will first look in module scope, then in enums that are in scope and at last within classes that are in scope.

I suggested something like it earlier too.

Anything that is more complicated than .identifier is not worth it and will only introduce unncessary complexity to the language syntax.

.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.

5 days ago

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

>

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

>

If it's not implemented with .identifier then I will oppose it.

I don't buy the "it will break code" point of view either.

[...] if you type .a then it will first look in module scope, then in enums that are in scope and at last within classes that are in scope.

I suggested something like it earlier too.

Anything that is more complicated than .identifier is not worth it and will only introduce unncessary complexity to the language syntax.

.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.

$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.

5 days ago

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

>

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

>

If it's not implemented with .identifier then I will oppose it.

+1
and it's a feature that was desperately needed anyway.

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.

5 days ago

On Friday, 25 November 2022 at 09:53:34 UTC, Dukc 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.

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.

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.

5 days ago

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

>

On Tuesday, 22 November 2022 at 01:43:25 UTC, Timon Gehr wrote:

>

_.member is also missing.

_.member could break existing code, sorry. :(

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.

4 days ago

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

>

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

>

On Tuesday, 22 November 2022 at 01:43:25 UTC, Timon Gehr wrote:

>

_.member is also missing.

_.member could break existing code, sorry. :(

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.

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?

3 days ago

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

>

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

>

On Tuesday, 22 November 2022 at 01:43:25 UTC, Timon Gehr wrote:
_.member could break existing code, sorry. :(
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.

$_ 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.

3 days ago

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

>

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?

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.