I'm consolidating some routines from std.string into std.array. They are
specialized for operating on arrays, and include the likes of insert,
remove, replace.
One question is whether operations should be performed in place or on a
copy. For example:
string s = "Mary has a lil lamb.";
// Imp
Andrei:
> One question is whether operations should be performed in place or on a
> copy. For example:
Strings are meant to be immutable, and the functional style is simpler to
understand and safer to use, so I firmly suggest the default (with shorter
names) functions to create a new string/ar
Strange, we are again on the opposite sides...
Second one looks much better to me.
I think, most of the time we need inplace, and it deserves the better
syntax.
Andrei Alexandrescu Wrote:
> So that would make copying the default behavior. Alternatively, we could
> make in-place the default behavior and ask for the Copy suffix:
Do what sort does. On another thought what about:
auto s = replace(s1[], "lil", "li'l");
isn't the empty [] the specification
so:
> Strange, we are again on the opposite sides...
> Second one looks much better to me.
> I think, most of the time we need inplace, and it deserves the better
> syntax.
In the meantime the world is going more functional... :-)
Bye,
bearophile
On Wednesday, January 19, 2011 15:33:16 Andrei Alexandrescu wrote:
> I'm consolidating some routines from std.string into std.array. They are
> specialized for operating on arrays, and include the likes of insert,
> remove, replace.
>
> One question is whether operations should be performed in pla
On 1/19/11 6:53 PM, Jonathan M Davis wrote:
On Wednesday, January 19, 2011 15:33:16 Andrei Alexandrescu wrote:
I'm consolidating some routines from std.string into std.array. They are
specialized for operating on arrays, and include the likes of insert,
remove, replace.
One question is whether
bearophile wrote:
auto s1 = replace(s, "lil", "li'l");
assert(s == "Mary has a lil lamb.");
You probably meant:
assert(s1 == "Mary has a lil lamb.");
Nope. (s1 == "Mary has a li'l lamb.") && (s == "Mary has a lil lamb.").
--
Simen
On Wednesday, January 19, 2011 17:10:07 Andrei Alexandrescu wrote:
> On 1/19/11 6:53 PM, Jonathan M Davis wrote:
> > On Wednesday, January 19, 2011 15:33:16 Andrei Alexandrescu wrote:
> >> I'm consolidating some routines from std.string into std.array. They are
> >> specialized for operating on arr
Andrei:
> Problem is, even though the example uses strings, the functions apply to
> all arrays.
Important general rule: if converting string functions into generic functions
makes them worse string functions, then don't move them to the algorithm
module, or create special string functions for
Andrei Alexandrescu Wrote:
> On 1/19/11 6:53 PM, Jonathan M Davis wrote:
> > On Wednesday, January 19, 2011 15:33:16 Andrei Alexandrescu wrote:
> >> I'm consolidating some routines from std.string into std.array. They are
> >> specialized for operating on arrays, and include the likes of insert,
>
And honestly, from the standpoint of code simplicity and
understandability,
there's a lot to be said for making copies being the default rather than
mutation. You can then use the InPlace versions if you need the boost in
efficiency.
- Jonathan M Davis
Isn't simplicity and understandability f
so:
> Isn't simplicity and understandability favors the in-place style on these
> type of algorithms?
Nope, functional-style code is what you are looking for :-)
> As Jesse Phillips said, it is same as sort.
You have to think of the normal sort as a performance hack, something that is
good
On Wednesday 19 January 2011 18:36:55 so wrote:
> > And honestly, from the standpoint of code simplicity and
> > understandability,
> > there's a lot to be said for making copies being the default rather than
> > mutation. You can then use the InPlace versions if you need the boost in
> > efficienc
On Wednesday 19 January 2011 18:23:14 Jerry Quinn wrote:
> Andrei Alexandrescu Wrote:
> > On 1/19/11 6:53 PM, Jonathan M Davis wrote:
> > > On Wednesday, January 19, 2011 15:33:16 Andrei Alexandrescu wrote:
> > >> I'm consolidating some routines from std.string into std.array. They
> > >> are speci
On 1/19/11 8:36 PM, so wrote:
And honestly, from the standpoint of code simplicity and
understandability,
there's a lot to be said for making copies being the default rather than
mutation. You can then use the InPlace versions if you need the boost in
efficiency.
- Jonathan M Davis
Isn't simpl
On 1/19/11 9:11 PM, Jonathan M Davis wrote:
On Wednesday 19 January 2011 18:36:55 so wrote:
And honestly, from the standpoint of code simplicity and
understandability,
there's a lot to be said for making copies being the default rather than
mutation. You can then use the InPlace versions if you
One common mistake newbies make in Python is calling the sorted method
and expecting it to sort in place:
>>> x = [3, 2, 1]
>>> sorted(x)
[1, 2, 3]< sorted returned a new list
>>> x
[3, 2, 1]< x stayed the same
>>>
There are a few functions in the Python lib that have "InPlace" added
to t
On 1/20/11, Andrej Mitrovic wrote:
> One common mistake newbies make in Python is calling the sorted method
> and expecting it to sort in place:
>
x = [3, 2, 1]
sorted(x)
> [1, 2, 3]< sorted returned a new list
x
> [3, 2, 1]< x stayed the same
>
> There are a few functi
Andrej Mitrovic:
> I think what might help out in D is if we had a way to mark some
> functions so the compiler guarantees that their return values *are
> not* to be discarded. For example, this code will compile:
>
> import std.stdio;
> import std.string;
> void main()
> {
> string s = "Mary
> If you have replace(str, "hello", "world");
> you don't know whether it's changed the value in place or if you're
throwing away a return value. However, if you have
> auto newStr = replace(str, "hello", "world");
> replaceInPlace(newStr, "world", "hello");
> it's quite clear that the first one re
If such an annotation was introduced, it should be the other way around.
But imo discarding a return value should always result in a warning,
the function returns something for a reason.
On Thursday 20 January 2011 03:51:48 Trass3r wrote:
> If such an annotation was introduced, it should be the other way around.
> But imo discarding a return value should always result in a warning,
> the function returns something for a reason.
Actually, there are plenty of cases where you throw a
Andrej Mitrovic:
> If the replace function is marked with some kind of @nodiscard
> annotation, then his would be a compile error since it doesn't make
> sense to construct a new string, return it, and discard it.
http://d.puremagic.com/issues/show_bug.cgi?id=5464
Bye,
bearophile
auto newStr = replace(str, "hello", "world");
replaceInPlace(newStr, "world", "hello");
it's quite clear that the first one returns a value and the the second
one does
it in place. Whereas if you have
auto newStr = replaceCopy(str, "hello", "world");
replace(newStr, "world", "hello");
the fi
You have to think of the normal sort as a performance hack, something
that is good because copying data wastes a lot of time, if the array is
large or if you have to sort an many small arrays. Normally in Python
you prefer sorted(), that returns a sorted copy, unless performance is
importan
On 20/01/11 10:33, Andrei Alexandrescu wrote:
I'm consolidating some routines from std.string into std.array. They are
specialized for operating on arrays, and include the likes of insert,
remove, replace.
One question is whether operations should be performed in place or on a
copy. For example:
In the meantime the world is going more functional... :-)
I love how they solve this problem, but if you go on that path while
ignoring the reality there wouldn't be much of a reason using D, no? :)
Jonathan M Davis Wrote:
> On Thursday 20 January 2011 03:51:48 Trass3r wrote:
> > If such an annotation was introduced, it should be the other way around.
> > But imo discarding a return value should always result in a warning,
> > the function returns something for a reason.
>
> Actually, there
On Thu, 20 Jan 2011 10:36:00 -0500, foobar wrote:
Jonathan M Davis Wrote:
On Thursday 20 January 2011 03:51:48 Trass3r wrote:
> If such an annotation was introduced, it should be the other way
around.
> But imo discarding a return value should always result in a warning,
> the function ret
Steven Schveighoffer wrote:
On Thu, 20 Jan 2011 10:36:00 -0500, foobar wrote:
Jonathan M Davis Wrote:
On Thursday 20 January 2011 03:51:48 Trass3r wrote:
> If such an annotation was introduced, it should be the other way
around.
> But imo discarding a return value should always result in a
Don:
> If you don't use the return value of a strongly pure, nothrow function,
> you could be given a 'expression has no effect' error.
> Currently the function call is silently dropped.
I have added this at the end of the enhancement request 5464 (but the error
message is different).
Bye,
bea
so:
> I didn't know that, this solution is what i meant.
> So, they didn't blindly enforce functional language rules to a
> non-functional language.
Python was designed lot of time ago by Guido that I think didn't know much
about functional programming. So they have first added an in-place sor
so:
> I don't understand how the first two are clear and the last two are not so.
> Where both have the name "replace" for different things, and replace to me
> means "replace in place".
> With this in hand, how is the first "replace" is quite clear?
In Python I am used to immutable strings, so
On Thursday, January 20, 2011 05:48:12 so wrote:
> > auto newStr = replace(str, "hello", "world");
> > replaceInPlace(newStr, "world", "hello");
> >
> > it's quite clear that the first one returns a value and the the second
> > one does
> > it in place. Whereas if you have
> >
> > auto newStr = r
On 1/20/11, Jonathan M Davis wrote:
> On Thursday 20 January 2011 03:51:48 Trass3r wrote:
>> If such an annotation was introduced, it should be the other way around.
>> But imo discarding a return value should always result in a warning,
>> the function returns something for a reason.
>
> Actually
On 01/20/2011 11:31 AM, bearophile wrote:
> Andrej Mitrovic:
>
>> I think what might help out in D is if we had a way to mark some
>> functions so the compiler guarantees that their return values *are
>> not* to be discarded. For example, this code will compile:
>>
>> import std.stdio;
>> import s
On 01/20/2011 12:33 AM, Andrei Alexandrescu wrote:
I'm consolidating some routines from std.string into std.array. They are
specialized for operating on arrays, and include the likes of insert,
remove, replace.
One question is whether operations should be performed in place or on a
copy. For exa
Is it ok to use:
In place:
trim( string )
replace( string, from, to )
or Copy:
trim( string, outstring )
replace( string, from, to, outstring )
Andrei Alexandrescu Wrote:
> I'm consolidating some routines from std.string into std.array. They are
> specialized for operating on arrays, and include the likes of insert,
> remove, replace.
>
> One question is whether operations should be performed in place or on a
> copy. For example:
>
>
replace is clearer in the first case, because you're getting the return
value.
...
I am really trying hard to understand this, but your reasons for first is
clearer then the second makes no sense to me i am sorry.
I still think second is clearer, but whatever, as long as i can see the
interf
so:
> Just check boost/string/replace, they have in place replaces default too.
> You might not like boost (some don't) but it is the closest example to D.
You will find D1 string functions are much more from here than from Boost:
http://docs.python.org/release/2.5.2/lib/string-methods.html
By
On 01/21/2011 07:47 PM, so wrote:
replace is clearer in the first case, because you're getting the
return value.
...
I am really trying hard to understand this, but your reasons for first
is clearer then the second makes no sense to me i am sorry.
I still think second is clearer, but whatever, a
On Friday, January 21, 2011 10:47:01 so wrote:
> > replace is clearer in the first case, because you're getting the return
> > value.
> > ...
>
> I am really trying hard to understand this, but your reasons for first is
> clearer then the second makes no sense to me i am sorry.
> I still think sec
On Friday, January 21, 2011 12:15:42 spir wrote:
> On 01/21/2011 07:47 PM, so wrote:
> >> replace is clearer in the first case, because you're getting the
> >> return value.
> >> ...
> >
> > I am really trying hard to understand this, but your reasons for first
> > is clearer then the second makes
On 01/21/2011 09:21 PM, Jonathan M Davis wrote:
The issue is when you don't look at the documentation or trying to avoid having
to look at the documentation. If you see
auto result = replace(str, "hello", "goodbye");
it's quite clear that a copy is taking place. And if a copy/slice is taking
pl
On Friday, January 21, 2011 12:48:57 spir wrote:
> On 01/21/2011 09:21 PM, Jonathan M Davis wrote:
> > The issue is when you don't look at the documentation or trying to avoid
> > having to look at the documentation. If you see
> >
> > auto result = replace(str, "hello", "goodbye");
> >
> > it's
On 01/21/2011 10:03 PM, Jonathan M Davis wrote:
I really don't find having functions returning results without altering their
arguments as the normal case to be odd at all, let alone misleading, since
that's what most functions actually do.
Same for me. I don't find having this version as the n
48 matches
Mail list logo
