Proposal: Don't require users to use undefined

Bas van Dijk v.dijk.bas at
Wed Oct 27 03:23:40 EDT 2010

On Wed, Oct 27, 2010 at 9:15 AM, Michael Snoyman <michael at> wrote:
> On Wed, Oct 27, 2010 at 9:01 AM, Bas van Dijk <v.dijk.bas at> wrote:
>> On Wed, Oct 27, 2010 at 7:57 AM, Michael Snoyman <michael at> wrote:
>>> On Wed, Oct 27, 2010 at 7:51 AM, Bas van Dijk <v.dijk.bas at> wrote:
>>>> On Tue, Oct 26, 2010 at 9:09 PM, Henning Thielemann
>>>> <lemming at> wrote:
>>>>> 4. In the future you may deprecate the immediate use of 'sizeOf' and
>>>>> 'alignment'.
>>>> We could deprecate sizeOf immediately in favor of sizeOfTagged.
>>>> Deprecating it doesn't break any code but does gives warnings so that
>>>> users are encouraged to upgrade. I don't see a reason to wait.
>>> We can't immediately switch to using sizeOfTagged since many people
>>> will still be using old versions of base. If we waited one cycle to
>>> deprecate the old functions, it won't annoy people. By the next cycle,
>>> in theory a majority of people will already have sizeOfTagged, and it
>>> would be feasible to switch our code to sizeOf.
>> Yes, that's what I meant. We should {-# DEPRECATE #-} sizeOf now and
>> provide sizeOfTagged as an alternative. In a further cycle we can
>> remove sizeOf.
> My point is that if you use DEPRECATE immediately, no one will be able
> to compile with -Wall -Werror. No one can reasonably switch over to
> sizeOfTagged until at least the next cycle, and by putting in a
> deprecation immediately, we'll start generating warnings immediately
> for writing code in the only reasonable way possible.

Ok I get your point. Then we could at least put a note in the
documentation that sizeOf is soon to be deprecated in favor of

(BTW Note that base-4.3 will also be deprecating block and unblock in
favor of mask. Maybe that should follow this procedure as well.)


More information about the Libraries mailing list