Why Strings as Classes?

[Michiel Helvensteijn]

Dee Girl wrote:

>> >> But putting that aside for the moment, are you saying you would allow
>> >> yourself to be deceived by a syntax detail? No, mentally attaching
>> >> O(1) to the *subscripting operator* is simply a legacy from C, where
>> >> it is syntactic sugar for pointer arithmetic.
>> > 
>> > I do not think so. I am sorry. If a[n] is not allowed then other array
>> > access primitive is allowed. Give index(a, n) as example. If language
>> > say index(a, n) is array access then it is big mistake for list to also
>> > define index(a, n). List maybe should define findAt(a, n). Then array
>> > also can define findAt(a, n). It is not mistake.
>> 
>> Yes, I agree for "array access". That term implies O(1), since it uses
>> the word "array". But I was argueing against the subscripting operator to
>> be forced into O(1).
> 
> I am sorry. I do not understand your logic. My logic was this. Language
> has a[n] for array index. My opinion was then a[n] should not be linear
> search. I said also you can replace a[n] with index(a, n) and my same
> reason is the same. How are you argueing?

Let me try again. I agree that you may impose complexity-restrictions in
function contracts. If you write a function called index(a, n), you may
impose the O(log n) syntax, for all I care. But the a[n] syntax is so
convenient that I would hate for it to be likewise restricted. I would like
to use it for lists and associative containers and the complexity may be
O(n). The programmer should just be careful.

> I did not want to get in this discussion. I see how it is confusing fast
> ^_^.

I find much of this subthread confusing. (Starting with the discussion of
Benji and superdan). It looks to me like 80% of the discussion is based on
misunderstandings.

>> Amortized complexity has nothing to do with it. Dynamic arrays have to
>> copy their elements and lists do not. It's as simple as that.
> 
> No, it is not. I am sorry! In STL there is copy. In D there is std.move. I
> think it only copies data by bits and clears source. And amortized
> complexity shows that there is o(1) bit copy on many append.

Yes, a bit-copy would be ok. I was thinking of executing the potentially
more expensive copy constructor. It's nice that D doesn't have to do this.

>> STL will choose the right sorting algorithm, given a specific
>> data-structure. But I am saying it may be possible also for the
>> data-structure to be automatically chosen, based on what the programmer
>> does with it.
> 
> I think this is interesting. Then why argueing for bad container design? I
> do not understand. Thank you, Dee Girl.

Where am I argueing for bad design? All I've been arguing for is looser
restrictions for the subscripting operator. You should be able to use it on
a list, even though the complexity is O(n). But if it is used often enough
(in a deeply nested loop), the compiler will probably automatically use an
array instead.

-- 
Michiel