what does 'deprecated' mean with respect to "bare structure types"?

[Luís Oliveira]

On Mon, Jun 10, 2013 at 10:07 PM, james anderson <james.anderson at setf.de> wrote:
>> The thing is, given a struct foo, the FOO type means different things
>> in different contexts. Sometimes it has pass-by-reference semantics,
>> other times it has pass-by-value semantics. This was less of an issue
>> when each context only had to handle one of the semantics, but now
>> that both are supported (thanks to cffi-libffi), we have to
>> disambiguate.
>
> what was it which precludes requiring the inflected forms for the newly introduced cases only?

It doesn't preclude it. As it stands, the (:struct foo) syntax is only
/required/ for the new cases.


>> There were two reasons for deprecating the bare struct type, then.
>> From the implementation point of view, the disambiguation code is
>> intrusive and error-prone so we'd like to remove it as soon as
>> possible.
>
> in itself, that does not convince.  the less-than-obvious reasons for variations at usage sites and the variations themselves would appear to this reader to be at least as intrusive and as error-prone as the much less numerous accommodations in the cffi code. from skimming the mailing list archive, it appears that this was a situation where the implications took some time to comprehend, but once they have been, what reason would exists, to require unnecessary forms? perhaps if either the problem were self-evident or the documentation would make a clearer case for the elaboration, it would be easier to follow your argument.

You are quite correct that the backwards compatibility code isn't as
bad as it once was. (I didn't remember the extent of the
simplification achieved in the last rewrite! :-))

Still, the API argument stands.

Cheers,

--
Luís Oliveira
http://r42.eu/~luis/