On 5/2/12, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> struct S { int x, y; }
> S s = { 1, 2 };
>
>  I think we should remove
> this feature.

But not this, right:

S s = { x : 1, y : 2 }; ?

On Wednesday, May 02, 2012 07:17:20 Maxim Fomin wrote:
> On Wednesday, 2 May 2012 at 03:38:41 UTC, Adam D. Ruppe wrote:
> > On Wednesday, 2 May 2012 at 03:22:02 UTC, Andrei Alexandrescu
> > 
> > wrote:
> >> One feature to remove stands out - the struct initialization: S s = { 1, 2 };
> > 
> > I could live without that one, because D has an alternative:
> > 
> > auto s = S(1, 2);
> 
> It has the same problem as the first one: members are part of the interface and a new one: struct literals are impossible if opCall is defined (if I am not mistaken).

Yes, members are part of the interface, but if {1, 2} isn't legal, then their order isn't part of the interface as far as constructing the object is concerned (the memory layout is, so low-level stuff could still be broken by swapping or adding member variables, but the construction doesn't have to stop working like it does with a C struct literal).

And defining opCall shouldn't have any effect on S(1, 2). S(1, 2) is clearly calling the constructor. The only reason that you would have a conflict is if you also defined a static opCall which conflicted. If a non-static opCall has _any_ effect on S(1, 2), then it's a bug.

- Jonathan M Davis

On Wednesday, 2 May 2012 at 05:25:40 UTC, Andrej Mitrovic wrote:
> On 5/2/12, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>> struct S { int x, y; }
>> S s = { 1, 2 };
>>
>>  I think we should remove
>> this feature.
>
> But not this, right:
>
> S s = { x : 1, y : 2 }; ?

Yes, these are named parameters.
Andrei's point could be made for just about everything that takes two (or more) consecutive integers, like a function signature, so I think it's a bit moot. Unfortunately, only named parameters can solve this problem, but then comes the problem of accepting both order of parameters and named parameters at the same time...

On Tuesday, 1 May 2012 at 21:03:35 UTC, foobar wrote:
>
> vote++
>
> I like your POV that operators are useful shortcuts (syntax
> sugar) meant for the end user whereas library authors should use
> the full function names for generic code. IIRC C++'s STL does the
> same - for instance the map::operator[] is a simple wrapper
> around map's functions.
>
> Is this included in D's style guide?

vote-------------

If something is a bad idea for a library, I don't see why it could be a good idea for the user code. After all, the standard library IS user code.
The fact that it's in a library or not doesn't change anything to the fact that your syntactic sugar is hiding a potential problem.

>
> No, it is not an O(1) operation, it is *close* to O(1) (as much sense as that statement can make). I don't know why you associate any particular complexity with 'in' in the first place. And I do think we're crippling the language, considering Python (and probably other languages) has had this feature since forever.
>
> I'm seriously worried. It seems to me like we're trying to cater to people who can't reason about the types in their program and the complexities of performing various operations on them. Since when did algorithmic complexity become a reason to take away syntax sugar?

+1

I do argee. opIn is handy for arrays, too. That the complexity would be linear and thus it should be disallowed is not a valid argument in my opinion, because with the exact same argument you could kick std.algorithm.find out of phobos. It is just obvious to every trained programmer that finding an element in an unordered list takes O(n).

Andrei Alexandrescu:

> It's a bit inappropriate to bind Walter to such a social contract upon having asked an informal question.

Those comments weren't required, but they improve the quality of this community. So it's work and time well spent. Every person attracted to work on D development is a chance to increase significantly the development speed.


> FWIW there is little agreement among answers.

Right, but a thread like this is comparable to the first phase of a Brainstorming process, where ideas are produced freely, where agreement is not required.
Later there is a phase of selection, that needs to be based on the quality of the single ideas; because technology/science decisions can't be based (too much) on popularity.


> Eliminating today's semantics of comma inevitably underlies the hope that it can be retrofitted for something else, which I think is near impossible without changing semantics of working code.

Removing/restricting the usage of the comma operator is probably able to avoid some bugs (and increase syntax uniformity in D code written by different programmers), so it has a usefulness even if later they are not used for tuple syntax. How much important such bugs are, is a judgement.


> One feature to remove stands out - the struct initialization:
>
> struct S { int x, y; }
> S s = { 1, 2 };
>
> This, was noted, makes the order of members effectively part of the struct's interface, which is subtly dangerous. I think we should remove this feature.

It's a partially redundant feature, and it's able to introduce some long-term rigidity in the code. On the other hand when you have to write many struct literals, nested inside other literals of different structs, repeating the names introduces a bit of extra redundant code.

Thank you for the answers,
bye,
bearophile

On 5/1/12 11:38 PM, Adam D. Ruppe wrote:
> On Wednesday, 2 May 2012 at 03:22:02 UTC, Andrei Alexandrescu wrote:
>> One feature to remove stands out - the struct initialization:
>> S s = { 1, 2 };
>
> I could live without that one, because D has an alternative:
>
> auto s = S(1, 2);
>
>
> And I'd be sad if you took that out, as I use it a lot, especially
> for trivial types:
>
> struct Html { string src; }
> struct Text { string src; }
> struct Point { int x; int y; }
> struct Size { int width; int height; }
>
> which I like because then we can use the types for overloading,
> static checks, etc., and it is very very simple to drop in and
> use.
>
> I guess there could be opCalls or constructors, but poo, it
> works now without that and I like it.

Well, so probably we shouldn't remove that feature either :o).

Andrei

On 5/2/12 12:20 AM, Jakob Ovrum wrote:
> S(...) does not exhibit the same problem as {...} exactly because it has
> constructors and static opCall. If you change the order of fields in S,
> you can write a constructor preserving the old behaviour.

Good observation. So indeed the { ... } case is inferior because there's no reasonable way for the library writer to defend against.

Andrei

On 5/2/12 6:15 AM, Tobias Pankrath wrote:
>
>>
>> No, it is not an O(1) operation, it is *close* to O(1) (as much sense
>> as that statement can make). I don't know why you associate any
>> particular complexity with 'in' in the first place. And I do think
>> we're crippling the language, considering Python (and probably other
>> languages) has had this feature since forever.
>>
>> I'm seriously worried. It seems to me like we're trying to cater to
>> people who can't reason about the types in their program and the
>> complexities of performing various operations on them. Since when did
>> algorithmic complexity become a reason to take away syntax sugar?
>
> +1
>
> I do argee. opIn is handy for arrays, too. That the complexity would be
> linear and thus it should be disallowed is not a valid argument in my
> opinion, because with the exact same argument you could kick
> std.algorithm.find out of phobos. It is just obvious to every trained
> programmer that finding an element in an unordered list takes O(n).

The problem here is making complexity an implementation detail of a uniform interface (e.g. over hashes and linear containers). That is fail.

Andrei

On 5/2/12 7:52 AM, bearophile wrote:
> Andrei Alexandrescu:
>> FWIW there is little agreement among answers.
>
> Right, but a thread like this is comparable to the first phase of a
> Brainstorming process, where ideas are produced freely, where agreement
> is not required.

Sorry, here I meant "agreement" in the statistical sense, i.e. there's not a lot of clear collection of features we should remove; for most features that some wanted to get rid of, others had gainful uses.

Andrei