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
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
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
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
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
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
On Sunday, 25 September 2016 at 13:45:01 UTC, Andrei Alexandrescu
wrote:
Ranges don't need necessarily an associated Iterable. This is
the case in other languages, too; Lisp/Scheme/Haskell/etc lists
are iterables and at the same time their own iterators. But
indeed std.container is designed to
On Sunday, September 25, 2016 15:45:01 Andrei Alexandrescu via Digitalmars-d
wrote:
> Ranges don't need necessarily an associated Iterable. This is the case
> in other languages, too; Lisp/Scheme/Haskell/etc lists are iterables and
> at the same time their own iterators. But indeed std.container
On Sunday, September 25, 2016 13:40:14 pineapple via Digitalmars-d wrote:
> On Sunday, 25 September 2016 at 11:48:38 UTC, Jonathan M Davis
>
> wrote:
> > It's because ranges are effectively a sliding window over
> > whatever they're iterating over.
>
> I think this is the difference in perception
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.
On 9/25/16 12:58 PM, pineapple wrote:
On Sunday, 25 September 2016 at 04:06:41 UTC, Jonathan M Davis wrote:
Considering that a random access range is essentially an abstraction
for a dynamic array and that ranges were designed with that in mind, I
don't know how you can argue that dynamic
On Sunday, 25 September 2016 at 11:48:38 UTC, Jonathan M Davis
wrote:
It's because ranges are effectively a sliding window over
whatever they're iterating over.
I think this is the difference in perception - ranges do not
_have_ to be sliding windows, they can just as well be windows
that
On Sunday, 25 September 2016 at 13:10:42 UTC, ZombineDev wrote:
But which opIndex and which length? Those of the container, or
those of the range? It doesn't make any sense to expect
container[].takeExactly(7).length to be different than 7. If
range.length returns the length of the container
On Sunday, 25 September 2016 at 10:58:24 UTC, pineapple wrote:
It gets under my skin that length and opIndex and opSlice
produce different results in phobos' ranges depending on one's
current position in the range. This doesn't make sense to me,
and the only reason I can conceive of it having
On Sunday, September 25, 2016 10:58:24 pineapple via Digitalmars-d wrote:
> On Sunday, 25 September 2016 at 04:06:41 UTC, Jonathan M Davis
>
> wrote:
> > Considering that a random access range is essentially an
> > abstraction for a dynamic array and that ranges were designed
> > with that in
On Sunday, 25 September 2016 at 04:06:41 UTC, Jonathan M Davis
wrote:
Considering that a random access range is essentially an
abstraction for a dynamic array and that ranges were designed
with that in mind, I don't know how you can argue that dynamic
arrays shouldn't be treated as ranges.
On Sunday, September 25, 2016 00:36:58 pineapple via Digitalmars-d wrote:
> On Thursday, 22 September 2016 at 12:51:59 UTC, Andrei
>
> Alexandrescu wrote:
> > On 9/22/16 6:38 AM, pineapple wrote:
> >> The greatest offender I've found is how in phobos, arrays do
> >> not behave
> >> as ranges
On Thursday, 22 September 2016 at 12:51:59 UTC, Andrei
Alexandrescu wrote:
On 9/22/16 6:38 AM, pineapple wrote:
The greatest offender I've found is how in phobos, arrays do
not behave
as ranges without importing the module defining their range
operations.
Would make sense to move those few
On Wednesday, 21 September 2016 at 21:14:15 UTC, H. S. Teoh wrote:
The problem here is that generic_code.d doesn't (and
shouldn't!) import
usertype.d, so usertype.opBinary is not visible in
generic_code.d. So
when algorithm() tries to look up the '+' operator in `t + u`,
it can't
find the
On Thursday, 22 September 2016 at 14:33:36 UTC, Andrei
Alexandrescu wrote:
On 9/22/16 10:20 AM, Jonathan M Davis via Digitalmars-d wrote:
The main problem with moving them there is auto-decoding.
front and popFront
for strings require std.utf in order to do their thing.
Druntime has it's own
On 23.09.2016 12:44, Stefan Koch wrote:
On Friday, 23 September 2016 at 08:50:56 UTC, Timon Gehr wrote:
FQN disables UFCS. Nothing specific to operators here.
There is no reason why there should be any difference between a + b
and a.opBinary!"+"(b). In fact, 2.opBinary!"+"(3) should work too.
On Friday, September 23, 2016 13:47:06 Sai via Digitalmars-d wrote:
> > The greatest offender I've found is how in phobos, arrays do
> > not behave as ranges without importing the module defining
> > their range operations.
>
> Could you please tell me what module is it? is it std.array?
It was,
The greatest offender I've found is how in phobos, arrays do
not behave as ranges without importing the module defining
their range operations.
Could you please tell me what module is it? is it std.array?
On Friday, 23 September 2016 at 08:50:56 UTC, Timon Gehr wrote:
FQN disables UFCS. Nothing specific to operators here.
There is no reason why there should be any difference between a
+ b and a.opBinary!"+"(b). In fact, 2.opBinary!"+"(3) should
work too.
Currently this is tricky to
On 22.09.2016 10:44, Jonathan M Davis via Digitalmars-d wrote:
On Thursday, September 22, 2016 00:14:52 H. S. Teoh via Digitalmars-d wrote:
Normally this isn't a problem (D's
module system will trigger an overload conflict and require explicit FQN
to unambiguously select the right overload),
On Thursday, 22 September 2016 at 05:38:53 UTC, HaraldZealot
wrote:
So it seems to be essential point. But because we already have
the same problem with UFCS, I don't see why we should prohibit
external overloading of operator, it is just inequality (in
political sense) for operators :)
I'm
On Thu, Sep 22, 2016 at 07:20:49AM -0700, Jonathan M Davis via Digitalmars-d
wrote:
> On Thursday, September 22, 2016 08:51:59 Andrei Alexandrescu via
> Digitalmars-d
> wrote:
> > On 9/22/16 6:38 AM, pineapple wrote:
> > > The greatest offender I've found is how in phobos, arrays do not
> > >
On 9/22/16 10:20 AM, Jonathan M Davis via Digitalmars-d wrote:
The main problem with moving them there is auto-decoding. front and popFront
for strings require std.utf in order to do their thing.
Yah, that's a little hurdle. -- Andrei
On Thursday, September 22, 2016 08:51:59 Andrei Alexandrescu via Digitalmars-d
wrote:
> On 9/22/16 6:38 AM, pineapple wrote:
> > The greatest offender I've found is how in phobos, arrays do not behave
> > as ranges without importing the module defining their range operations.
>
> Would make sense
On 9/22/16 6:38 AM, pineapple wrote:
The greatest offender I've found is how in phobos, arrays do not behave
as ranges without importing the module defining their range operations.
Would make sense to move those few primitives to object.d. I've been
thinking of that a long time ago but back
On Wednesday, 21 September 2016 at 19:01:40 UTC, Timon Gehr wrote:
There is no technical reason that would make the implementation
of this feature difficult, if that is your question.
Basically, the rationale is: external operators cannot be used
in generic code that does not import the
On Thursday, 22 September 2016 at 08:58:54 UTC, HaraldZealot
wrote:
So let's vote for the following sentence:
"It would be good to have an operator overloading even without
support in generic function"
Yes
On Thursday, 22 September 2016 at 08:53:26 UTC, HaraldZealot
wrote:
OK, it seems to me it's time to investigate a community opinion.
So let's vote for the following sentence:
"It would be good to have an operator overloading even without
support in generic function"
On Thursday, 22 September 2016 at 07:14:52 UTC, H. S. Teoh wrote:
It's not so simple. The UFCS operator overload could be
declared in a different module from the type itself. Then
there is no guarantee that it will be found. Multiple calls to
the same template function with the same
On Thursday, September 22, 2016 00:14:52 H. S. Teoh via Digitalmars-d wrote:
> Normally this isn't a problem (D's
> module system will trigger an overload conflict and require explicit FQN
> to unambiguously select the right overload), but FQN's are not an option
> when the call is made from
On Thu, Sep 22, 2016 at 06:09:39AM +, HaraldZealot via Digitalmars-d wrote:
> On Thursday, 22 September 2016 at 05:38:53 UTC, HaraldZealot wrote:
> > And problem with generic code solve independently for all UFCS
> > functions including operators.
>
> Unfortunately I don't know compiler and
On Thursday, 22 September 2016 at 05:38:53 UTC, HaraldZealot
wrote:
And problem with generic code solve independently for all UFCS
functions including operators.
Unfortunately I don't know compiler and all related stuff
internally (time to change this ;) ), but it seems to me there is
a way
On Wednesday, 21 September 2016 at 21:14:15 UTC, H. S. Teoh wrote:
Thank you both, I see now.
So it seems to be essential point. But because we already have
the same problem with UFCS, I don't see why we should prohibit
external overloading of operator, it is just inequality (in
political
On Wed, Sep 21, 2016 at 08:53:06PM +, HaraldZealot via Digitalmars-d wrote:
> On Wednesday, 21 September 2016 at 19:01:40 UTC, Timon Gehr wrote:
> >
> > Basically, the rationale is: external operators cannot be used in
> > generic code that does not import the module defining the operators.
>
On 21.09.2016 22:53, HaraldZealot wrote:
On Wednesday, 21 September 2016 at 19:01:40 UTC, Timon Gehr wrote:
Basically, the rationale is: external operators cannot be used in
generic code that does not import the module defining the operators.
Could you give some elaborate example, for now I
On Wednesday, 21 September 2016 at 19:01:40 UTC, Timon Gehr wrote:
Basically, the rationale is: external operators cannot be used
in generic code that does not import the module defining the
operators.
Could you give some elaborate example, for now I can't imagine
what your mean.
On Wednesday, 21 September 2016 at 19:01:40 UTC, Timon Gehr wrote:
Basically, the rationale is: external operators cannot be used
in generic code that does not import the module defining the
operators.
So why not have the struct/class explicitly import external
operators? You can do this
On 21.09.2016 21:01, Timon Gehr wrote:
On 21.09.2016 19:57, HaraldZealot wrote:
So if someone has real rationale not to have operator overloading as
external function I'm curios to arguments.
[1] http://dlang.org/rationale.html
There is no technical reason that would make the
On 21.09.2016 19:57, HaraldZealot wrote:
So if someone has real rationale not to have operator overloading as
external function I'm curios to arguments.
[1] http://dlang.org/rationale.html
There is no technical reason that would make the implementation of this
feature difficult, if that
On Wednesday, 21 September 2016 at 17:57:17 UTC, HaraldZealot
wrote:
In current D, overloading operator like "+" with external
function is prohibited. There is the rationale [1] (see second
paragraph).
[...]
I am completely agree. We should support external operator
overloading for ndslice
In current D, overloading operator like "+" with external
function is prohibited. There is the rationale [1] (see second
paragraph).
BUT this rationale is totally UNCONVINCING. I can say that resume
of rationale is: "it is impossible because it brakes some C++
patterns and behaviour".
46 matches
Mail list logo
