On Sunday, 25 September 2016 at 13:57:04 UTC, Jonathan M Davis wrote:
> The way it works now is how it's always worked with dynamic arrays and ranges in D. If you're trying do anything else, you're just going to run into problems in the long run - particularly when interacting with code written by anyone else. So, while you're obviously free to do whatever you want with your own code, don't expect Phobos or D code in general to change how ranges fundamentally work.

That change is exactly what I'm arguing against - that the front, popFront, etc. functions defined for dynamic arrays in phobos should not be adopted by the core language.

On Thursday, 22 September 2016 at 12:51:59 UTC, Andrei Alexandrescu wrote:
> Would make sense to move those few primitives to object.d. I've been thinking of that a long time ago but back then there was a vague stance that object.d shouldn't contain templates. Since then that has changed. -- Andrei

Please do not do this - there ways to handle ranges other than the approach phobos has taken. That's it, that's the point I'm trying to make.

On 9/25/16 4:05 PM, pineapple wrote:
> On Sunday, 25 September 2016 at 13:57:04 UTC, Jonathan M Davis wrote:
>> The way it works now is how it's always worked with dynamic arrays and
>> ranges in D. If you're trying do anything else, you're just going to
>> run into problems in the long run - particularly when interacting with
>> code written by anyone else. So, while you're obviously free to do
>> whatever you want with your own code, don't expect Phobos or D code in
>> general to change how ranges fundamentally work.
>
> That change is exactly what I'm arguing against - that the front,
> popFront, etc. functions defined for dynamic arrays in phobos should not
> be adopted by the core language.
>
> On Thursday, 22 September 2016 at 12:51:59 UTC, Andrei Alexandrescu wrote:
>> Would make sense to move those few primitives to object.d. I've been
>> thinking of that a long time ago but back then there was a vague
>> stance that object.d shouldn't contain templates. Since then that has
>> changed. -- Andrei
>
> Please do not do this - there ways to handle ranges other than the
> approach phobos has taken. That's it, that's the point I'm trying to make.

We learned with time that any step we're trying to take toward progress in a matter of design (i.e. no mechanical rules, reasonable people may disagree), a faction will strongly oppose it. I speculate this has to do with our community being self-selected as opinionated folks who don't do well with conventional wisdom.

At the same time, we can't let this gridlock development of D. We must go with what we think is good.

It seems you want to define ranges with similar syntax but subtle semantic differences, e.g. r.front and r[0] to mean different things. The entire Phobos is designed under the assumptions that ranges work a specific way, so in order to design a different mechanism you may want to use different syntactic interfaces.


Andrei

On Sunday, September 25, 2016 16:50:04 Andrei Alexandrescu via Digitalmars-d wrote:
> It seems you want to define ranges with similar syntax but subtle semantic differences, e.g. r.front and r[0] to mean different things. The entire Phobos is designed under the assumptions that ranges work a specific way, so in order to design a different mechanism you may want to use different syntactic interfaces.

The reality of the matter is that anyone who tries to define the range primitives to work differently than how Phobos uses them (and druntime in various places even if it's not in object.d yet) is going to be screwed as soon as they interact with code written by anyone else. Anyone looking to make r[0] do something different than give you r.front might as well just redefine popFront to mean popBack and vice versa for all that it's going to work with other people's code.

So, if they want their code to work with anyone else's code they pretty much need to use their own set of range primitives that do not conflict with the standard ones rather than trying to redefine the standard ones. And if they don't care about interacting with anyone else's code, they can always just fork druntime and Phobos to make them do whatever they want. But trying to redefine some of the basic primitives that D's runtime and standard library use while still trying to interact with anyone else's code is a recipe for disaster.

- Jonathan M Davis

On Sunday, 25 September 2016 at 15:25:38 UTC, Jonathan M Davis wrote:
> So, if they want their code to work with anyone else's code they pretty much need to use their own set of range primitives that do not conflict with the standard ones rather than trying to redefine the standard ones. And if they don't care about interacting with anyone else's code, they can always just fork druntime and Phobos to make them do whatever they want. But trying to redefine some of the basic primitives that D's runtime and standard library use while still trying to interact with anyone else's code is a recipe for disaster.
>
> - Jonathan M Davis

I don't mind writing my own code rather than interacting with someone else's, and I severely dislike many of the design decisions made regarding phobos. Which is why I've been building my own alternative to the standard library that I can use as a basis for software I develop. It depends on phobos for only a handful of things, and I'm working toward a point where I won't need it for anything. I recognize that the preference is unusual, but I insist on my and others' ability to pursue such a preference.

On Sunday, 25 September 2016 at 14:50:04 UTC, Andrei Alexandrescu wrote:
> It seems you want to define ranges with similar syntax but subtle semantic differences, e.g. r.front and r[0] to mean different things. The entire Phobos is designed under the assumptions that ranges work a specific way, so in order to design a different mechanism you may want to use different syntactic interfaces.

I have no problem with phobos being phobos, and treating ranges as it does. I don't want the core language to adopt the same way of treating ranges because while I recognize that it is far too late to change phobos' way of thinking about ranges - much less the community's - I think it was a mistake and that the quality of D as a language shouldn't suffer for its sake. The core language should define the bare minimum that it needs to for ranges to be a useful concept - as it does now - and should leave the rest up to phobos or whatever else is actually implementing the ranges.

On Sunday, 25 September 2016 at 14:50:04 UTC, Andrei Alexandrescu wrote:
> I speculate this has to do with our community being self-selected as opinionated folks who don't do well with conventional wisdom.

You have described me to a T.

On 9/25/2016 6:45 AM, Andrei Alexandrescu wrote:
> Yah, it comes as a surprise to many that static arrays are more akin to structs
> than to arrays. They really are records that happen to have several elements of
> the same type. Providing indexing for them is a convenience that somewhat adds
> to the confusion, and converting to dynamic arrays is unsafe because it
> essentially escapes the innards of the struct. Statically-sized arrays are odd,
> that's for sure, and that's the case in C and C++ as well.

I'd like to emphasize that this is an important insight. A static array is semantically equivalent to a struct with fields of all the same type, and the fields can be accessed by index rather than field name. This insight has driven some simplifying assumptions internal to how the compiler is implemented, as well as the specification for how things work (like passing a static array as a function parameter works like passing a struct).

Another simplifying insight is that a struct is a tuple of fields. I tried to generalize this by having the arguments to a function be a tuple as well, but ran afoul of the ABI for calling conventions, argghh. It would really be awesome to have tuples, structs, static arrays, and function argument lists be literally the same thing, but sadly that does not seem practical at the moment.

On 9/25/16 9:48 AM, Jonathan M Davis via Digitalmars-d wrote:
> On Sunday, September 25, 2016 13:10:42 ZombineDev via Digitalmars-d wrote:
>> D's built-in dynamic arrays are hidden from you and you only get
>> to interact with them by referring to their elements by using
>> slices.
>
> That's a common misconception propagated by Steven's otherwise excellent
> article. As far as the official language spec goes, T[] _is_ the dynamic
> array. What backs it is irrelevant as far as that goes. It's just that if
> it's backed by the GC, then when you append to it, the GC might not have to
> allocate a new memory buffer for the array. All of the operations on a
> dynamic array work the same regardless of what backs it, and focusing on the
> memory buffer being the array risks causing you problems when you have to
> deal with dynamic arrays backed by something else.

D can call an animal that quacks, has a flat bill, and feathers a sparrow all it wants, but it sure doesn't act like one ;)

-Steve