On 10 Jun 2013, at 10:41 PM, Luís Oliveira wrote:
On Mon, Jun 10, 2013 at 8:51 PM, james anderson james.anderson@setf.de wrote:
it appears that the semantics of the elementary form is unambiguously known and supported in all contexts, that there is no indication of impending changes which would change this situation, and that, given these circumstances, the deprecation warning is gratuitous and can actually be ignored.
is this a true comprehension of the situation?
Indeed, we've done our best not to break backwards compatibility. So, if you're pressed for time, you can safely ignore the warnings for now.
We probably overlooked the annoyance that the style-warning may be causing. You can muffle the warning in the following less-than-ideal way:
(handler-bind ((alexandria:simple-style-warning (lambda (warning) (when (alexandria:starts-with-subseq "bare references to struct types are deprecated." (simple-condition-format-control warning)) (muffle-warning warning))))) (load-your-ffi-code-here))
[ Hooking this up with ASDF is left as an exercise for the reader. :-) ]
please excuse my somewhat narrow view of the the world, but when it comes to "hooking up", asdf is the last thing which comes to mind, thank you.
if i have overlooked or disregarded some key aspect of this change, please advise.
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?
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.
From the API point of view, the bare struct type became even more schizophrenic.
a pointer to the pertinent discussion would help. as it stands, when looking at the objectionable source sites, the first question which is occurs is "what am i missing here and why do i need to know it?"
There's no scheduled date for the removal of the bare struct type, but it won't be removed without a proper and timely warning.
thank you,