Against deprecating aliases

[Jacob Carlborg]

On 2011-09-29 20:18, Jonathan M Davis wrote:
> On Thursday, September 29, 2011 09:09 Jacob Carlborg wrote:
>> On 2011-09-29 08:36, Jonathan M Davis wrote:
>>> On Thursday, September 29, 2011 08:22:41 Jacob Carlborg wrote:
>>>> On 2011-09-28 21:56, Jonathan M Davis wrote:
>>>>> Having toUTF and toUTFz is a marked improvement in many cases -
>>>>> especially for generic code. They're being added regardless of what the
>>>>> deal with toUTF16z is.
>>>>>
>>>>> The reason that toUTF16z is being removed is essentially because Andrei
>>>>> is very much opposed to having functions with specific types in their
>>>>> names and thinks that they should all be generic. Personally, I'm not
>>>>> opposed to keeping toUTF16z as an alias or wrapper to toUTFz. It's
>>>>> Andrei that seems to feel stongly about it. So, if enough people really
>>>>> want to keep toUTF16z, then I think that that can happen.
>>>>
>>>> Seems a bit arbitrary what gets deprecated with the old API left in
>>>> place and what gets deprecated with the old API removed.
>>>
>>> I'm not sure that I understand. Very little gets deprecated with the old
>>> API immediately removed, and _everything_ which gets deprecated will be
>>> eventually removed (or it wouldn't be deprecated). What are you thinking
>>> about in particular?
>>
>> Lately if feels like when new functionally (or things were renamed) was
>> added the old was just removed without keeping aliases or wrappers.
>>
>> I base that on what I've read here lately, people are complaining that
>> functions are just gone. But I might be wrong or I've missed something.
>> Or maybe people just complaining about functions are about to be removed.
>
> I'm not aware of functions just being gone. Certainly, if I caused that to
> happen anyway, I screwed up. I think that the complaints are either about how
> deprecation messages have been being handled or that the change is happening
> in the first place. For instance, for what Andrej is doing, he wants to keep
> toUTF16z, so he's unhappy about it being scheduled for deprecation. And given
> the cost of making toUTFz appropriately generic, he has a good argument for
> it, and we may very well end up keeping it. But I believe that the complaints
> about stuff going away or being replaced have been because stuff was scheduled
> for deprecation, not because it actually went away. The closest that I can
> think of to a function actually going away is a case or two where a function
> was further genericized, and it ended up taking a range rather than an array,
> so it stopped working with immutable arrays, and to my knowledge, all of the
> functions in std.array have been fixed so that that is no longer an issue.
>
> - Jonathan M Davis

Then my bad.

-- 
/Jacob Carlborg