Final by default?

[Kapps]

On Saturday, 15 March 2014 at 18:18:28 UTC, Walter Bright wrote:
> On 3/15/2014 2:21 AM, Paulo Pinto wrote:
>> In any language with properties, accessors also allow for:
>>
>> - lazy initialization
>>
>> - changing the underlying data representation without 
>> requiring client code to
>> be rewritten
>>
>> - implement access optimizations if the data is too costly to 
>> keep around
>
> You can always add a property function later without changing 
> user code.

In many situations you can't. As was already mentioned, ++ and 
taking the address of it were two such situations.

ABI compatibility is also a large problem (less so in D for now, 
but it will be in the future). Structs change, positions change, 
data types change. If users use your struct directly, accessing 
its fields, then once you make even a minor change, their code 
will break in unpredictable ways. This was a huge annoyance for 
me when trying to deal with libjpeg. There are multiple versions 
and these versions have a different layout for the struct. If the 
wrong library is linked, the layout is different. Since it's a D 
binding to a C file, you can't just use the C header which you 
know to be up to date on your system, instead you have to make 
your own binding and hope for the best. They tr
y to work around this by making you pass in a version string when 
creating the libjpeg structs and failing if this string does not 
exactly match what the loaded version. This creates a further 
mess. It's a large problem, and there's talk of trying to 
eventually deprecate public field access in libjpeg in favour of 
accessors like libpng has done (though libpng still uses the 
annoying passing in version since they did not use accessors from 
the start and some fields remained public). Accessors are 
absolutely required if you intend to make a public library and 
exposed fields should be avoided completely.