A few general thoughts

[Daniel Gibson]

Am 29.04.2011 13:11, schrieb Francisco Almeida:
> On 29-04-2011 12:37, Daniel Gibson wrote:
>> Am 29.04.2011 12:11, schrieb lenochware:
>>>> This has been acknowledged. Yes, removing delete in D2 will break
>>>> compatibility with existing code. However, I'm sure that at an early
>>>> stage, the compiler will probably issue error messages once it
>>>> encounters delete statements, for which the fix is quite easy: just
>>>> remove them, and recompile. As an unfortunate side effect, a few other
>>>> problems might occur, especially for shared objects. But refactoring to
>>>> a simpler system, in which the garbage collector is trusted to manage
>>>> the heap, should be easy.
>>>
>>> Yes, I was speaking generally here about "breaking compatibility"
>>> philosophy.
>>> I agree that delete probably will not be such problem - but I would
>>> prefer mark
>>> features deprecated
>>> before it will be really removed and write only warning when compiled
>>> - in case it
>>> is possible. (For example some datatype was removed in d2 (bit? - I am
>>> not sure)
>>> which is one of error messages which I get when I try compile my
>>> project with
>>> incompatible library) People don't have to know what is planned for
>>> removing.
>>> Moreover there is not complete list of changes in d2. Or is?
>>
>> Who said that delete will not be marked deprecated before it's removed?
> 
> I apologize, I meant "warning" instead of "error". Deprecation warnings,
> obviously.

Once a feature is deprecated, the compiler will treat using it as an
error - *if* you don't use the "-d" switch ("Allow deprecated features").
I think this should be acceptable for you?

Cheers,
- Daniel