On 10 Jun 2013, at 10:41 PM, Luís Oliveira wrote: > On Mon, Jun 10, 2013 at 8:51 PM, james anderson <james.ander...@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,
